Given my limited experience with java, I can only answer this from a point of view from other programming languages. 1) Code unreachable is not an error, but a warning. It doesn't stop the program from running. 2) The code isn't really unreachable: what if some other exception is thrown? /Mike
Hi Sujit, Let me clear your doubt here. There is no question of code not been reachable here. The line at //2 is definitely reachable and returns "10.0" as expected , you may run the following code and check the answer yourself.
Mikael, In JAVA an unreacheable CODE IS AN ERROR.. You may check the following code :
Hope I have cleared your doubts. Ravindra Mohan.
Joined: May 16, 2001
Thanks for poining that out. Didn't know that... /Mike
Hi all, I found this in JLS which explains the reason why the system behaves this way it try-catch-finally constructs. quote: ----------- 14.16 The return Statement A return statement returns control to the invoker of a method (�8.4, �15.12) or constructor (�8.8, �15.9). ReturnStatement: return Expressionopt ; A return statement with no Expression must be contained in the body of a method that is declared, using the keyword void, not to return any value (�8.4), or in the body of a constructor (�8.8). A compile-time error occurs if a return statement appears within an instance initializer or a static initializer (�8.7). A return statement with no Expression attempts to transfer control to the invoker of the method or constructor that contains it. To be precise, a return statement with no Expression always completes abruptly, the reason being a return with no value. A return statement with an Expression must be contained in a method declaration that is declared to return a value (�8.4) or a compile-time error occurs. The Expression must denote a variable or value of some type T, or a compile-time error occurs. The type T must be assignable (�5.2) to the declared result type of the method, or a compile-time error occurs. A return statement with an Expression attempts to transfer control to the invoker of the method that contains it; the value of the Expression becomes the value of the method invocation. More precisely, execution of such a return statement first evaluates the Expression. If the evaluation of the Expression completes abruptly for some reason, then the return statement completes abruptly for that reason. If evaluation of the Expression completes normally, producing a value V, then the return statement completes abruptly, the reason being a return with value V. If the expression is of type float and is not FP-strict (�15.4), then the value may be an element of either the float value set or the float-extended-exponent value set (�4.2.3). If the expression is of type double and is not FP-strict, then the value may be an element of either the double value set or the double-extended-exponent value set. It can be seen, then, that a return statement always completes abruptly. The preceding descriptions say "attempts to transfer control" rather than just "transfers control" because if there are any try statements (�14.19) within the method or constructor whose try blocks contain the return statement, then any finally clauses of those try statements will be executed, in order, innermost to outermost, before control is transferred to the invoker of the method or constructor. Abrupt completion of a finally clause can disrupt the transfer of control initiated by a return statement. ---- My two cents. Thanks