Compile time check of Intialization and Non-reachable code

I read somewhere that if the compiler is able to determine that a code is unreachable then it will flag that as an error.

In the following code it will flag statement (4) as an error while not statement (2). But both these statements are unreachable.


If I comment line (3) and uncomment line (4) then the compiler is OK with it. But even in that case statement (4) is unreachable.
Similarly comiler is able to recognize that variable iVal is initialized by statement (1) but in some cases it is unable to determine it....

So can anyone tell me the exact behaviour how the compiler works in determining which statements are unreachable and which variables have been initialized....

I hope anyone can help....
[ August 10, 2008: Message edited by: Ankit Garg ]

Hi Ankit

I compiled your code and noticed that if you change the order of the case statements ie put the default case at last and then comment out the return statement of the default case it is not showing any problem .

so i am thinking that the compiler checks the last case statement and if it has return (which means exit the current itteration) the it understands that it is not going to reach the last println statement(line 4) and its showing the error.

In the case of first println statement if you don't comment it out it will be a syntax error bcos after the bracket it should start with a case statement.

About that println statement in case 30 ... it will not be reached at any point of time but since it is a case may be the compiler allows it.

correct me if I am wrong.

I compiled your code and noticed that if you change the order of the case statements ie put the default case at last and then comment out the return statement of the default case it is not showing any problem .

You don't even need to change the order of the statements to do this. Just simply comment out statement (3) and the program will compile....



But the main thing is that the last case label is also not reachable.
So there is no mean of checking statement (3) as even that will not be reachable......Why doesn't the compiler checks this......That's the real question....

ok i got your point i will try to answer it.

Ankit may be since iVal is not final or static it can change at runtime ...so the compiler might not think the case 30 is never reached.What do you say ?

oops! it was my fault..........if the value of iVal is 30 then the last case get's executed.....I thought that since there is a default before case 30: so the default will hide the last case.........

Sorry for bothering!!!

no problem ..finally you got it

Hi to all

Here's my analysis, please correct me if I'm wrong

The default is always the last choice. I noticed that when I change iConst value to 10 and change the code to



The output is Displayed even though default comes first before case iConst:

But in case 30:, i believe that the compiler is able to determine that it is the last case of this switch. The compiler can
tell that any code after the return of case 30: will be unreachable.

Now notice if the code is changed to



again, the compiler know that the default is the last for this switch. No case statment left.

I hope this helps.
[ August 11, 2008: Message edited by: Quirino Gervacio ]

One more thing to you all.............

Compiler sees that there is no any break statement in the switch scope, hence there is (or may be?) a "fall through" and statement(1) will be (or may be?) reached and it is "return". Hence assuming satement(2) not reacheable.

Following works

So, am I correct? Need your opinion..................
[ August 11, 2008: Message edited by: ARIJIT DARIPA ]

Originally posted by ARIJIT DARIPA:


class SwitchTries{
public static void main(String[] args){
int i=10;
switch(i){
case 15:
if(false) break;
return;
case 10:
return;
default:
return;
case 30:
return;
}
System.out.println("Can be Reached");
}
}

Nice observation dude....but why can't the compiler deduce that the break statement can't be reached???

Take this example
int iVal;
if(true)
{
iVal = 10;//(1)
}
else
{
System.out.println(15);
}
//(2)

Now here the compiler knows that iVal has been intialized by (2). That's because (1) will always be executed. But if the compiler can see this than why can't it see that the else block never get's executed. That must be a compilation error.....but it's not???
[ August 11, 2008: Message edited by: Ankit Garg ]

I think ARIJIT is right (if we're on the same boat)

the algorithm could be:

but for

if(true){}
else{}

may be the compiler here assumes that you know what you are doing even though us, humans can tell that the else will never get executed :-)

and for
int i;
if(false){
i=0;
}
else{}
System.out.print(i); //(1) variable i might not have been initialized
the compiler can now easily tell that no statement above that initializes i and would be very much happy to yell the error.

but if you initialize i in else (1) will be OK. maybe because the compiler
can also tell that i is now initialized. it doesn't really matter whether the statement the initialized it is reachable, as long as there is an assignment operation in i, the compiler is happy.

and of course, i could be wrong here.

i hope this helps.
[ August 11, 2008: Message edited by: Quirino Gervacio ]

Originally posted by Ankit Garg:

int iVal;
if(true)
{
iVal = 10;//(1)
}
else
{
System.out.println(15);
}

Originally posted by Quirino Gervacio:

if(true){}
else{}

may be the compiler here assumes that you know what you are doing even though us, humans can tell that the else will never get executed :-)

This code is equivalent to the following

Now look at the following equivalency

Had the compiler spat error on the else block at line 1, it would have to say there is a compilation error at line 3.
Oh! imagine, we have to know the values of static final variables before comparing them.

Opinion please.............................
Thanks to Ankit Garg for telling me how to put spaces in my post.
Thanks to Quirino Gervacio for support.
[ August 11, 2008: Message edited by: ARIJIT DARIPA ]

answer is pretty simple
your compiler buddy rely on his default buddy and in your case he has cheated keeping return with him.
So he need someone in his life who can be with him in those last moment of switch case.
So
either you keep hte last case nt to hav return so tht compiler can hope some sympathy or hav your default( compiler reliable buddy) with out return (so irrespective of its location it will always be there for compiler)

Originally posted by ARIJIT DARIPA:


Had the compiler spat error on the else block at line 1, it would have to say there is a compilation error at line 3.
Oh! imagine, we have to know the values of static final variables before comparing them.

I didn't understand what you said. I also modified your code a bit...


Here the compiler knows that line 1 will always be executed. If it does so then why can't it figure out that line 2 will never be executed. Is it fool or is there a reason......

@ Ankit may be compiler is thinking that we are doing it knowing that it is going to execute in that way because i don't see a reason here since its final variable we cant change it.
so its obvious that else is not executed.
or
the if {} else {} is for giving an option to execute if or else ... so may be compiler doesn't care if only if is executed all the time

correct me if i am wrong.

Originally posted by Ankit Garg:


I didn't understand what you said. I also modified your code a bit...

Please look at the next equivalent code also of my previous post, because that is telling the story. I think you will have at least a bit from that.

w

Hi Guys,

This is a very interesting thread and it's also way outside the scope of the real exam! So, for those of you who are focusing your studies strictly on the SCJP exam, you can skip this thread.

hth,

Bert

Hi, I think the Compiler doesn't care about the expression given on the
if ( expression ) {} else {}. Even when the value returned by the expression be always true. The compiler will never check it. I think this happens because is senseless that the compiler has to check if the condition is always true or maybe like Ankit said, it's a fool jeje

Even here



I think the compiler only checks that the expression given returns a boolean and if it's like that the it's fine.


Srry for the english

@Gustavo you said that the compiler doesn't checks the value of the boolean expression...but it actually does that....if you have seen the earlier codes carefully, then you might have read this

int a;
if(true)
{
a=10;
}
System.out.println(a);//no error

The compiler knows that a will always be intialized, but even then if you introduce an else with this if, then compiler doesn't complain that the statements within the else are not reachable.....This is the main question...