question on continue and break statements

[sreedevi langoju]

Hi,
I am preparing for the OCAJP8 certification.While taking the mock exams i found this question.
Here when this break z; statement will get execute ? If not will it become unreachable statement which gives compilation error ?
when i run this program in eclipse it is running successfully .output: 3567

public class ContinueBreak {
	static String o="";
	public static void main(String[] args) {
		z: for(int x=3;x<8;x++)
		{
			if(x==4)
				continue;
			if(x==4)
				break z;
			o+=x;	
		}
		System.out.println(o);
	}

}

Thanks in advance,
Sree

[Henry Wong]

Yes. Obviously (to us), the break statement is unreachable.

However, "no". It will *not* generate a compilation error. First, "if" statements / blocks, are exempted from the unreachable checks. This is to allow for conditional code. Second, even if it wasn't exempt from the checks, it has to be detectable by the compiler. This means that the condition should be a compile time constant.

So, no compiler error.

Henry

[Anton Golovin]

sreedevi langoju wrote:Hi,
I am preparing for the OCAJP8 certification.While taking the mock exams i found this question.
Here when this break z; statement will get execute ? If not will it become unreachable statement which gives compilation error ?
when i run this program in eclipse it is running successfully .output: 3567

public class ContinueBreak {
	static String o="";
	public static void main(String[] args) {
		z: for(int x=3;x<8;x++)
		{
			if(x==4)
				continue;
			if(x==4)
				break z;
			o+=x;	
		}
		System.out.println(o);
	}

}

Thanks in advance,
Sree

Sreedevi,

The continue statement immediately goes to the next iteration of the loop whereas the break statement exits the loop. If you have nested loops, and you use continue or break from within the innermost loop in order to exit an enclosing loop, you can use the break and continue statement with a label so that the compiler knows which loop you are exiting.

I think on reading the code, it would have to be some pretty sophisticated static analyzer to report it as unreachable code. It is unreachable for all means and purposes, but the compiler is not designed to catch this sort of thing.

With best regards,

Anton.

[Junilu Lacar]

Anton, you'd be surprised at the kind of sophisticated analysis a compiler can actually do. The reason is actually as Henry stated: to allow for conditional compilation of sections of code, Java does not consider if-statements when looking for unreacheable code. The JLS even includes an example. See the end of this page https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.21

[sreedevi langoju]

Thanks Henry Wong ,Anton Golovin and Junilu Lacar for the reply. Now i understand ..

As you mentioned , i refer the below section  from this link     https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.html#jls-14.21  which explains if statements are kind of exceptional cases.

As an example, the following statement results in a compile-time error:

while (false) { x=3; }

because the statement x=3; is not reachable; but the superficially similar case:

if (false) { x=3; }

does not result in a compile-time error. An optimizing compiler may realize that the statement x=3; will never be executed and may choose to omit the code for that statement from the generated class file, but the statement x=3; is not regarded as "unreachable" in the technical sense specified here.

The rationale for this differing treatment is to allow programmers to define "flag variables" such as:

static final boolean DEBUG = false;
and then write code such as:

if (DEBUG) { x=3; }

The idea is that it should be possible to change the value of DEBUG from false to true or from true to false and then compile the code correctly with no other changes to the program text.

This ability to "conditionally compile" has no relationship to binary compatibility (§13 (Binary Compatibility)). If a set of classes that use such a "flag" variable are compiled and conditional code is omitted, it does not suffice later to distribute just a new version of the class or interface that contains the definition of the flag. The classes that use the flag will not see its new value, so their behavior may be surprising, but no LinkageError will occur. A change to the value of a flag is, therefore, binary compatible with pre-existing binaries, but not behaviorally compatible.