• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Compile time check of Intialization and Non-reachable code

 
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 54
Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ankit Garg
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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....
 
Vinod Kumar Kommineni
Ranch Hand
Posts: 54
Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ok i got your point i will try to answer it.
 
Vinod Kumar Kommineni
Ranch Hand
Posts: 54
Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Ankit Garg
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!!!
 
Vinod Kumar Kommineni
Ranch Hand
Posts: 54
Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
no problem ..finally you got it
 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ankit Garg
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Quirino Gervacio
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Arijit Daripa
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
 
Ankit Garg
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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......
 
Vinod Kumar Kommineni
Ranch Hand
Posts: 54
Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@ 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.
 
Arijit Daripa
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
w
 
author
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ankit Garg
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@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...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic