Do I always have to return something using Worker Thread in Swing? What if I don't have any return value? I just want to use the worker thread to run an infinite for loop... so what to return? and even if I write a dummy return statement after the infinite for loop, say for e.g return 0; then also it will probably say "code not reachable".
I suspect you haven't tried it. The code you've suggested in the comment should work fine:
public Object construct() {
for (;;) {
Node.execution();
Clock.incrementTimeTick();
System.out.println(Clock.getTimeInTick());
repaint();
}
// End of loop is unreachable, so no need for a return statement.
}
A tight loop like this seems like a bad idea to me, and the repaint() code will need to be made appropriately thread-safe, but it should compile...
Personally I prefer to use while (true) for "forever" loops, but for (;;) should work too.
Implement the worker as SwingWorker<Void, SomeObject> and just return null. Trick the compiler about the infinite loop. Make it depending on some method that in the runtime always return true.
A method like the follow will compile without any compilation errors:
public Object foo() {
for (;;) {
// do something ... or nothing
}
}
The reason is that any statement following the for loop is unreachable, according to the rules set out in the JLS 14.21. Specifically
Any for loop with no condition expression (or a condition expression that is a compile-time constant expression with value true) cannot "complete normally".
Any statement in a block that is preceded by a statement which cannot complete normally is unreachable.
Related
This question already has answers here:
Does Java recognize infinite loops?
(8 answers)
Closed 9 months ago.
recently I started to do some experiments with different language compilers due to my studies in Compiler Design,
and I found a very odd thing, that happens in Java
and that is, as you may know, if we have a method with no return path, there is no requirement to return any value
So if I have the next method, this is totally fine, since this is an infinite loop
private int Run(){
while (true){
}
}
but once I but break statement anywhere even with impossible condition non-reachable area the compile complains
so the next java code will not compile
private int Run(){
while (true){
if(false){
break;
}
}
}
but compared to c#
int Run()
{
while (true)
{
if (true == false)
{
break;
}
}
}
or c++
int Run() {
while (true)
{
if (false) {
break;
}
}
}
both will compile just fine, even in c# most refactoring tools say that the code is redundant because the compiler will finally eliminate it since it is a compile time constant
I think this issue is somehow related to Halting problem, but can not figure out where is the issue exactly.
so if anyone has an idea of what happening with java please tell me, Thank you.
The behaviour if the code
private int Run(){
while (true){
if(false){
break;
}
}
}
is a compile-error or not is defined in the Java Language Specification, specifically in Chapter 14. Blocks and Statements. Statements can "complete normally" or "complete abruptly". Based on these information, the execution of other statements are affected.
Chapter 14.15. The break Statement defines that the break statement will complete the "break target" normally:
A break statement with no label attempts to transfer control to the innermost enclosing switch, while, do, or for statement of the immediately enclosing method or initializer; this statement, which is called the break target, then immediately completes normally.
Also chapter 14.21. Unreachable Statements defines the following:
A while statement can complete normally iff at least one of the following is true:
The while statement is reachable and the condition expression is not a constant expression (§15.28) with value true.
There is a reachable break statement that exits the while statement.
("iff" means "if and only if", as defined in chapter 14.21 and explained in https://en.wikipedia.org/wiki/If_and_only_if)
The first condition is false in our case as we have the condition expression true for the while loop. Notice that this section defines that a while loop with while(true) {...} without any break statements will not "complete normally".
Now we need to check if there is a "reachable" break statement.
The break statement is "reachable" because of the following chain:
The block that is the body of a constructor, method, instance initializer, or static initializer is reachable.
The {...} block of the method.
The first statement in a non-empty block that is not a switch block is reachable iff the block is reachable.
So the while loop is reachable.
The contained statement is reachable iff the while statement is reachable and the condition expression is not a constant expression whose value is false.
As the while loop is reachable and the condition expression is not false, the inner block {...} of the while statement is reachable. The if() statement inside the {...} block is reachable again because it is the first statement in a reachable block (see above).
The then-statement is reachable iff the if-then statement is reachable.
The {...} block of the if-statement is reachable, so is the first statement break of that block (see above).
Notice that the condition of the if() statement is not checked during this analysis of the compiler (as indicated in the non-normative section at the bottom of chapter 14.21).
This whole "reachable" checks means that the while loop can complete normally. This means that the {...} block of the method can complete normally, see chapter 14.2. Blocks:
If all of these block statements complete normally, then the block completes normally
And that means that a return statement is required, as chapter 8.4.7. Method Body defines it:
If a method is declared to have a return type (§8.4.5), then a compile-time error occurs if the body of the method can complete normally (§14.1).
Therefore, you need a return statement, even though you have a break statement which cannot be executed. But having the reachable break statement there changes everything. This is what is "happening with java", regardless of what C# or C++ is doing.
I am getting Unreachable code compilation error when I am using true in while loop
my code:
LoginService();
while(true)
{
//some stuff
}
LogoutService(); //getting compilation error Unreachable code
How to handle the situation ?
Your getting that error because you have an infinite loop due to your true condition in the while loop. You should reevaluate the reason for your while loop and provide an appropriate exit out of it.
You are seeing this error because the compiler has detected an infinite loop. To fix this, try this version, which uses a boolean variable to control loop execution:
LoginService();
boolean flag = true;
while (flag) {
//some stuff
if (condition) {
flag = false;
}
}
LogoutService();
This fixes your compiler error and also makes your logic explicit for when the loop should continue executing.
As much as possible (I would suggest never) use a while(true) !
Just put an exit condition in your while :
boolean exitLoop = false;
while(!exitLoop){ /*do stuff*/}
Your while(true) never ends and so LogoutService() will never be called! Have some logic that breaks the loop.
while(true){...} without any break inside means that the code after the while statement could never been reached. It is a compilation error.
14.21. Unreachable Statements
It is a compile-time error if a statement cannot be executed because
it is unreachable.
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.
So to solve your issue, make the last statement reachable.
For example :
LoginService();
while(true)
{
// ...
if (someCondition){
break;
}
}
LogoutService();
I want to check if there are no elements in an array.
private Player[] players = new Player[maxPlayers];
public boolean activePlayer(){
for(int i = 0; i < players.length; i++){
if(players[i] != null) {
return true;
break;
}
}
return false;
}
ItelliJ marks break; red with the message unreachable statement. What does this mean and how can I fix this?
The return statement right before the break will immediately end the method, so the break will never be reached.
in simple terms, the if the first if condition is true then it will only goto "return true;" and exit... if it does not go into the If block then it will continue to loop through and end at "return false;" So yes intelliJ is right. it should never come to the "break;"
the return true; will actually do the break for you and you don't need to do it explicitly and it will return to where ever you are calling the function "activePlayers()"
If you explain why you are adding a break, we may be able to help you further
Think through the serial behavior of the program, one line at a time. If it makes it past the conditional statements, it will hit the return statement. In Java, return terminates a function, returning control to the calling function and potentially returning a value as well. The break line will never be touched!
This might help you understand the flow of control in a Java program: http://www.dickbaldwin.com/java/Java026.htm
If you add more information about what you would like the program to do/ what you expect from the break statement, we'd be happy to help!
We use return to return a value back to the calling method, so therefore once control goes inside the if block the value true is returned to the calling method hence the break will never be reached.
To put it simply, return ends the execution of the current method and returns a value back to the caller.
Well, in Java, returning a value in a function will, in order,:
1. stop executing the code inside of the function
2. return the value in the function
ItelliJ is a very snappy and "intelligent" code checker that tells you when something is wrong or buggy.
It is giving you the error, "unreachable statement" because the "break" statement never gets executed because when you return "true"... (look back at the first part of the answer)... the break statement never gets executed.
So it is therefore an "unreachable" statement that will never be executed in any case whatsoever.
I encountered a situation where a non-void method is missing a return statement and the code still compiles.
I know that the statements after the while loop are unreachable (dead code) and would never be executed. But why doesn't the compiler even warn about returning something? Or why would a language allow us to have a non-void method having an infinite loop and not returning anything?
public int doNotReturnAnything() {
while(true) {
//do something
}
//no return statement
}
If I add a break statement (even a conditional one) in the while loop, the compiler complains of the infamous errors: Method does not return a value in Eclipse and Not all code paths return a value in Visual Studio.
public int doNotReturnAnything() {
while(true) {
if(mustReturn) break;
//do something
}
//no return statement
}
This is true of both Java and C#.
Why would a language allow us to have a non-void method having an infinite loop and not returning anything?
The rule for non-void methods is every code path that returns must return a value, and that rule is satisfied in your program: zero out of zero code paths that return do return a value. The rule is not "every non-void method must have a code path that returns".
This enables you to write stub-methods like:
IEnumerator IEnumerable.GetEnumerator()
{
throw new NotImplementedException();
}
That's a non-void method. It has to be a non-void method in order to satisfy the interface. But it seems silly to make this implementation illegal because it does not return anything.
That your method has an unreachable end point because of a goto (remember, a while(true) is just a more pleasant way to write goto) instead of a throw (which is another form of goto) is not relevant.
Why doesn't the compiler even warn about returning something?
Because the compiler has no good evidence that the code is wrong. Someone wrote while(true) and it seems likely that the person who did that knew what they were doing.
Where can I read more about reachability analysis in C#?
See my articles on the subject, here:
ATBG: de facto and de jure reachability
And you might also consider reading the C# specification.
The Java compiler is smart enough to find the unreachable code ( the code after while loop)
and since its unreachable, there is no point in adding a return statement there (after while ends)
same goes with conditional if
public int get() {
if(someBoolean) {
return 10;
}
else {
return 5;
}
// there is no need of say, return 11 here;
}
since the boolean condition someBoolean can only evaluate to either true or false, there is no need to provide a return explicitly after if-else, because that code is unreachable, and Java does not complain about it.
The compiler knows that the while loop will never stop executing, hence the method will never finish, hence a return statement is not necessary.
Given your loop is executing on a constant - the compiler knows that it's an infinite loop - meaning the method could never return, anyway.
If you use a variable - the compiler will enforce the rule:
This won't compile:
// Define other methods and classes here
public int doNotReturnAnything() {
var x = true;
while(x == true) {
//do something
}
//no return statement - won't compile
}
The Java specification defines a concept called Unreachable statements. You are not allowed to have an unreachable statement in your code (it's a compile time error). You are not even allowed to have a return statement after the while(true); statement in Java. A while(true); statement makes the following statements unreachable by definition, therefore you don't need a return statement.
Note that while Halting problem is undecidable in generic case, the definition of Unreachable Statement is more strict than just halting. It's deciding very specific cases where a program definitely does not halt. The compiler is theoretically not able to detect all infinite loops and unreachable statements but it has to detect specific cases defined in the specification (for example, the while(true) case)
The compiler is smart enough to find out that your while loop is infinite.
So the compiler cannot think for you. It cannot guess why you wrote that code. Same stands for the return values of methods. Java won't complain if you don't do anything with method's return values.
So, to answer your question:
The compiler analyzes your code and after finding out that no execution path leads to falling off the end of the function it finishes with OK.
There may be legitimate reasons for an infinite loop. For example a lot of apps use an infinite main loop. Another example is a web server which may indefinitely wait for requests.
In type theory, there is something called the bottom type which is a subclass of every other type (!) and is used to indicate non-termination among other things. (Exceptions can count as a type of non-termination--you don't terminate via the normal path.)
So from a theoretical perspective, these statements that are non-terminating can be considered to return something of Bottom type, which is a subtype of int, so you do (kind of) get your return value after all from a type perspective. And it's perfectly okay that it doesn't make any sense that one type can be a subclass of everything else including int because you never actually return one.
In any case, via explicit type theory or not, compilers (compiler writers) recognize that asking for a return value after a non-terminating statement is silly: there is no possible case in which you could need that value. (It can be nice to have your compiler warn you when it knows something won't terminate but it looks like you want it to return something. But that's better left for style-checkers a la lint, since maybe you need the type signature that way for some other reason (e.g. subclassing) but you really want non-termination.)
There is no situation in which the function can reach its end without returning an appropriate value. Therefore, there is nothing for the compiler to complain about.
Visual studio has the smart engine to detect if you have typed a return type then it should have a return statement with in the function/method.
As in PHP Your return type is true if you have not returned anything. compiler get 1 if nothing has returned.
As of this
public int doNotReturnAnything() {
while(true) {
//do something
}
//no return statement
}
Compiler know that while statement itself has a infinte nature so not to consider it. and php compiler will automatically get true if you write a condition in expression of while.
But not in the case of VS it will return you a error in the stack .
Your while loop will run forever and hence won't come outside while; it will continue to execute. Hence, the outside part of while{} is unreachable and there is not point in writing return or not. The compiler is intelligent enough to figure out what part is reachable and what part isn't.
Example:
public int xyz(){
boolean x=true;
while(x==true){
// do something
}
// no return statement
}
The above code won't compile, because there can be a case that the value of variable x is modified inside the body of while loop. So this makes the outside part of while loop reachable! And hence compiler will throw an error 'no return statement found'.
The compiler is not intelligent enough (or rather lazy ;) ) to figure out that whether the value of x will be modified or not. Hope this clears everything.
"Why doesn't the compiler even warn about returning something? Or why would a language allow us to have a non-void method having an infinite loop and not returning anything?".
This code is valid in all other languages too (probably except Haskell!). Because the first assumption is we are "intentionally" writing some code.
And there are situations that this code can be totally valid like if you are going to use it as a thread; or if it was returning a Task<int>, you could do some error checking based on the returned int value - which should not be returned.
I may be wrong but some debuggers allow modification of variables. Here while x is not modified by code and it will be optimized out by JIT one might modify x to false and method should return something (if such thing is allowed by C# debugger).
The specifics of the Java case for this (which are probably very similar to the C# case) are to do with how the Java compiler determines if a method is able to return.
Specifically, the rules are that a method with a return type must not be able to complete normally and must instead always complete abruptly (abruptly here indicating via a return statement or an exception) per JLS 8.4.7.
If a method is declared to have a return type, then a compile-time
error occurs if the body of the method can complete normally.
In other words, a method with a return type must return only by using
a return statement that provides a value return; it is not allowed to
"drop off the end of its body".
The compiler looks to see whether normal termination is possible based on the rules defined in JLS 14.21 Unreachable Statements as it also defines the rules for normal completion.
Notably, the rules for unreachable statements make a special case just for loops that have a defined true constant expression:
A while statement can complete normally iff at least one of the
following is true:
The while statement is reachable and the condition expression is not a
constant expression (§15.28) with value true.
There is a reachable break statement that exits the while statement.
So if the while statement can complete normally, then a return statement below it is necessary since the code is deemed reachable, and any while loop without a reachable break statement or constant true expression is considered able to complete normally.
These rules mean that your while statement with a constant true expression and without a break is never considered to complete normally, and so any code below it is never considered to be reachable. The end of the method is below the loop, and since everything below the loop is unreachable, so is the end of the method, and thus the method cannot possibly complete normally (which is what the complier looks for).
if statements, on the other hand, do not have the special exemption regarding constant expressions that are afforded to loops.
Compare:
// I have a compiler error!
public boolean testReturn()
{
final boolean condition = true;
if (condition) return true;
}
With:
// I compile just fine!
public boolean testReturn()
{
final boolean condition = true;
while (condition)
{
return true;
}
}
The reason for the distinction is quite interesting, and is due to the desire to allow for conditional compilation flags that do not cause compiler errors (from the JLS):
One might expect the if statement to be handled in the following
manner:
An if-then statement can complete normally iff at least one of the
following is true:
The if-then statement is reachable and the condition expression is not
a constant expression whose value is true.
The then-statement can complete normally.
The then-statement is reachable iff the if-then statement is reachable
and the condition expression is not a constant expression whose value
is false.
An if-then-else statement can complete normally iff the then-statement
can complete normally or the else-statement can complete normally.
The then-statement is reachable iff the if-then-else statement is
reachable and the condition expression is not a constant expression
whose value is false.
The else-statement is reachable iff the if-then-else statement is
reachable and the condition expression is not a constant expression
whose value is true.
This approach would be consistent with the treatment of other control
structures. However, in order to allow the if statement to be used
conveniently for "conditional compilation" purposes, the actual rules
differ.
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.
Why does the conditional break statement result in a compiler error?
As quoted in the loop reachability rules, a while loop can also complete normally if it contains a reachable break statement. Since the rules for the reachability of an if statement's then clause do not take the condition of the if into consideration at all, such a conditional if statement's then clause is always considered reachable.
If the break is reachable, then the code after the loop is once again also considered reachable. Since there is no reachable code that results in abrupt termination after the loop, the method is then considered able to complete normally, and so the compiler flags it as an error.
Given the following code sample:
public class WeirdStuff {
public static int doSomething() {
while(true);
}
public static void main(String[] args) {
doSomething();
}
}
This is a valid Java program, although the method doSomething() should return an int but never does. If you run it, it will end in an infinite loop. If you put the argument of the while loop in a separate variable (e.g. boolean bool = true) the compiler will tell you to return an int in this method.
So my question is: is this somewhere in the Java specification and are there situation where this behavior might be useful?
I'll just quote the Java Language Specification, as it's rather clear on this:
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.
...
A while statement can complete normally iff at least one of the following is true:
The while statement is reachable and the condition expression is not a constant expression with value true.
There is a reachable break statement that exits the while statement.
...
Every other statement S in a nonempty block that is not a switch block is reachable iff the statement preceding S can complete normally.
And then apply the above definitions to this:
If a method is declared to have a return type, then every return statement (§14.17) in its body must have an Expression. A compile-time error occurs if the body of the method can complete normally (§14.1).
In other words, a method with a return type must return only by using a return statement that provides a value return; it is not allowed to "drop off the end of its body."
Note that it is possible for a method to have a declared return type and yet contain no return statements. Here is one example:
class DizzyDean {
int pitch() { throw new RuntimeException("90 mph?!"); }
}
Java specification defines a concept called Unreachable statements. You are not allowed to have an unreachable statement in your code (it's a compile time error). A while(true); statement makes the following statements unreachable by definition. You are not even allowed to have a return statement after the while(true); statement in Java. Note that while Halting problem is undecidable in generic case, the definition of Unreachable Statement is more strict than just halting. It's deciding very specific cases where a program definitely does not halt. The compiler is theoretically not able to detect all infinite loops and unreachable statements but it has to detect specific cases defined in the spec.
If you are asking if infinite loops can be useful, the answer is yes. There are plenty of situations where you want something running forever, though the loop will usually be terminated at some point.
As to your question: "Can java recognized when a loop will be infinite?" The answer is that it is impossible for a computer to have an algorithm to determine if a program will run forever or not. Read about: Halting Problem
Reading a bit more, your question is also asking why the doSomething() function does not complain that it is not returning an int.
Interestingly the following source does NOT compile.
public class test {
public static int doSomething() {
//while(true);
boolean test=true;
while(test){
}
}
public static void main(String[] args) {
doSomething();
}
}
This indicates to me that, as the wiki page on the halting problem suggests, it is impossible for there to be an algorithm to determine if every problem will terminate, but this does not mean someone hasn't added the simple case:
while(true);
to the java spec. My example above is a little more complicated, so Java can't have it remembered as an infinite loop. Truely, this is a weird edge case, but it's there just to make things compile. Maybe someone will try other combinations.
EDIT: not an issue with unreachable code.
import java.util.*;
public class test {
public static int doSomething() {
//while(true);
while(true){
System.out.println("Hello");
}
}
public static void main(String[] args) {
doSomething();
}
}
The above works, so the while(true); isn't being ignored by the compiler as unreachable, otherwise it would throw a compile time error!
Yes, you can see these 'infinite' loops in some threads, for example server threads that listen on a certain port for incoming messages.
So my question is: is this somewhere in the Java specification
The program is legal Java according to the specification. The JLS (and Java compiler) recognize that the method cannot return, and therefore no return statement is required. Indeed, if you added a return statement after the loop, the Java compiler would give you a compilation error because the return statement would be unreachable code.
and are there situation where this behavior might be useful?
I don't think so, except possibly in obscure unit tests.
I occasionally write methods that will never return (normally), but putting the current thread into an uninterruptible infinite busy-loop rarely makes any sense.
After rereading the question....
Java understands while(true); can never actually complete, it does not trace the following code completely.
boolean moo = true;
while (moo);
Is this useful? Doubtful.
You might be implementing a general interface such that, even though the method may exit with a meaningful return value, your particular implementation is a useful infinite loop (for example, a network server) which never has a situation where it should exit, i.e. trigger whatever action returning a value means.
Also, regarding code like boolean x = true; while (x);, this will compile given a final modifier on x. I don't know offhand but I would imagine this is Java's choice of reasonable straightforward constant expression analysis (which needs to be defined straightforwardly since, due to this rejection of programs dependent on it, it is part of the language definition).
Some notes about unreachable statements:
In java2 specs the description of 'unreachable statement' could be found. Especially interesting the following sentence:
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.
So, it is not obviously possible to exit from while (true); infinite loop. However, there were two more options: change cached values or hack directly into class file or JVM operating memory space.