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.
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 variable's contents were read from a file?
- the variable wasn't local and could be modified by another thread?
- the variable relied on some user input?
The compiler is clearly not checking for your simpler case because it's forgoing that road altogether. Why? Because it's much harder forbidden by the spec. See section 14.20:
(By the way, my compiler does complain when the variable is declared final.)
