• 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

continue statement

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is a error here
CASE1


outer:
for(int i =0; i<10; i++) {

continue outer;
System.out.println(".......i.."+i);
}



Compile time error
unreachable statement
System.out.println(".......i.."+i);



but this code works fine

CASE2



final int j = 0;


outer:
for(int i =0; i<10; i++) {

if(j>=0) {
continue outer;
}

System.out.println(".......i.."+i);
}




Why does the compiler complains in first case that "i" is not reachable, whereas in case2 also the "i" wont also be reachable.
Why the compiler did not complain in CASE2 even though the if condition is known at compile time because of constant boolean expression.
[ November 23, 2007: Message edited by: gurpreet singh ]
 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the Java Language Specification 3.0, 14.21 Unreachable Statements:


It is a compile-time error if a statement cannot be executed because it is unreachable. Every Java compiler must carry out the conservative flow analysis specified here to make sure all statements are reachable.

This section is devoted to a precise explanation of the word "reachable." The idea is that there must be some possible execution path from the beginning of the constructor, method, instance initializer or static initializer that contains the statement to the statement itself. The analysis takes into account the structure of statements. Except for the special treatment of while, do, and for statements whose condition expression has the constant value true, the values of expressions are
not taken into account in the flow analysis.

For example, a Java compiler will accept the code:

even though the value of n is known at compile time and in principle it can be known at compile time that the assignment to k can never be executed.


[ November 23, 2007: Message edited by: Jan van Mansum ]
 
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes thats correct. But if the variable is a final variable then its guraenteed that its value will never change and hence the compiler should give a compile time error in Gurpeet's second case.
final int j = 0;


outer:
for(int i =0; i<10; i++) {

if(j>=0) {
continue outer;
}

System.out.println(".......i.."+i);
}

Above since j is final its guarenteed at compile time that its value will never change and hence it should have shown a compile time error, But infact it does not. So what is the reason?
Thanks
Deepak
 
Ranch Hand
Posts: 513
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Deepak Jain:
Yes thats correct. But if the variable is a final variable then its guraenteed that its value will never change and hence the compiler should give a compile time error in Gurpeet's second case.



That seems true to our human reasoning, but isn't the case for the Java compiler. As the JLS excerpt that Jan posted says, Java will only carry out a very specific and conservative flow analysis algorithm to determine reachability. It's conservative in the sense that it's not exhaustive--not every statement that is really unreachable will be flagged as unreachable by the algorithm.

Read the JLS excerpt again, and observe that it provides an example of a code fragment containing a line that we humans know is unreachable, but which the flow analysis algorithm will not flag as unreachable.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic