Look at the following infinite while
loop in Java. It causes a compile-time error for the statement below it.
while(true) {
System.out.println("inside while");
}
System.out.println("while terminated"); //Unreachable statement - compiler-error.
The following same infinite while
loop, however works fine and doesn't issue any errors in which I just replaced the condition with a boolean variable.
boolean b=true;
while(b) {
System.out.println("inside while");
}
System.out.println("while terminated"); //No error here.
In the second case also, the statement after the loop is obviously unreachable because the boolean variable b
is true still the compiler doesn't complain at all. Why?
Edit : The following version of while
gets stuck into an infinite loop as obvious but issues no compiler errors for the statement below it even though the if
condition within the loop is always false
and consequently, the loop can never return and can be determined by the compiler at the compile-time itself.
while(true) {
if(false) {
break;
}
System.out.println("inside while");
}
System.out.println("while terminated"); //No error here.
while(true) {
if(false) { //if true then also
return; //Replacing return with break fixes the following error.
}
System.out.println("inside while");
}
System.out.println("while terminated"); //Compiler-error - unreachable statement.
while(true) {
if(true) {
System.out.println("inside if");
return;
}
System.out.println("inside while"); //No error here.
}
System.out.println("while terminated"); //Compiler-error - unreachable statement.
Edit : Same thing with if
and while
.
if(false) {
System.out.println("inside if"); //No error here.
}
while(false) {
System.out.println("inside while");
// Compiler's complain - unreachable statement.
}
while(true) {
if(true) {
System.out.println("inside if");
break;
}
System.out.println("inside while"); //No error here.
}
The following version of while
also gets stuck into an infinite loop.
while(true) {
try {
System.out.println("inside while");
return; //Replacing return with break makes no difference here.
} finally {
continue;
}
}
This is because the finally
block is always executed even though the return
statement encounters before it within the try
block itself.
Because true is constant and b can be changed in the loop.
Expressions are evaluated at run time so, when replacing the scalar value "true" with something like a boolean variable, you changed a scalar value into a boolean expression and thus, the compiler has no way to know it at compilation time.
The latter is not unreachable. The boolean b still has the possibility of being altered to false somewhere inside the loop causing an ending condition.
The compiler can easily and unequivocally prove that the first expression always results in an infinite loop, but it's not as easy for the second. In your toy example it's simple, but what if:
The compiler is clearly not checking for your simpler case because it's forgoing that road altogether. Why? Because it's
much harderforbidden by the spec. See section 14.21:(By the way, my compiler does complain when the variable is declared
final
.)It is simply because the compiler doesn't to too much baby sitting work, though it is possible.
The example shown is simple and reasonable for compiler to detect the infinite loop. But how about we insert 1000 lines of code without any relationship with variable
b
? And how about those statements are allb = true;
? The compiler definitely can evaluate the result and tell you it is true eventually inwhile
loop, but how slow it will be to compile a real project?PS, lint tool definitely should do it for you.
The compiler is not sophisticated enough to run through the values that
b
may contain (though you only assign it once). The first example is easy for the compiler to see it will be an infinite loop because the condition is not variable.