Author Topic:   Has anybody had a doubt like this...
maha anna
posted March 11, 2000 12:07 PM             
We all know that local vars have to be explicitly initialized before they are used. If it is initialized using if..else statement then, it has to be initialized in all branches of the if..else (i.e in the if block and else block) statement. Otherwise if we use only if statement it has to be if(true) statement in order to be sure of the initialization of the local var. In all the above cases the compiler does not complain. It knows at compile time itself, the local var is sure to have an initial val, at run time. In the foll. code the first commented part explains this.
But the for the 2nd case , which i have in the foll. code the method checkTrueLiteral(), which supposed to return an int value, if I put only the throw new Exception() , (at any part of the method first/last/middle of the method)the compiler does not complain that the method is not returning an int value. But when I use if(true) throw new Exception() , it wakes up and complains that the method doesn't return an int value.
What is bothering me is in effect, if(true) throw new Exception() and just throw new Exception() are all same isn't it?. Otherwise, it shouldn't accept the if(true) localIntVar=100; also right? Doesn't it seem to have a double standard?
Can anybody say anything about this?
Thank you
maha anna

class Test {
public static void main(String[] args) throws Exception{
static int checkTrueLiteral() throws Exception{
int localIntVar;

throw new Exception("I'm outta here!");

[This message has been edited by maha anna (edited March 11, 2000).]

Rolf Weasel
ranch hand
posted March 12, 2000 02:23 AM             
The rules for definite assignment are laid out in the JLS. These are applicable only to assignment and they are used to verify that method variables are properly initialized before use. The rules cover the if statement situation.

As far as non-void methods go, the requirement is that they should never complete normally. Completing normally means reaching the '}' at the end of the method. Hence, return statements cause abnormal completion. So do thrown exceptions.
The compile-time rules followed by the compiler in this situation will defer from the rules for definite assignment. My guess is that the compiler tries to verify that the terminating '}' of the method is unreachable, using rules similar to the ones it employs for locating unreachable statements. These rules are detailed .
The methodology for unreachable statements has a certain quirk when considering if statements with a constant boolean value. While one would expect that
if (false)
would cause any following statement(s) to be marked unreachable, the grand-daddies of Java decided otherwise. Their reasoning was that people would want to use lines like:
if (DEBUG) System.out.println("Variable x="+x);
(where DEBUG is a boolean constant) all over their code for debugging, etc. So they decided that in such situations, the value of the boolean constant would not be considered.
Coming back to Anna's code, everything was hunkeydorey when the
if (true)
was commented out. The terminating '}' was unreachable since the Exception was thrown on the last line.
When she removed the commenting, all hell broke loose! The boolean constant in
if (true) throw new Exception("I'm outta here");
was not considered and the compiler concluded that normal termination was possible. Hence the error message.
Note that the following code would also result in the same error:
if (true) return 1;
Also, if-else constructs are handled correctly:
if (true) throw new Exception("I'm outta here!");
else throw new Exception("I'm outta here!");

works fine, as does
if (true) return 1;
else throw new Exception("I'm outta here!");

May the Moose be with you.

[This message has been edited by Rolf Weasel (edited March 12, 2000).]

maha anna
posted March 12, 2000 07:24 AM             
Thank you very much Rolf.
maha anna