File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Question about unreachable code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Question about unreachable code" Watch "Question about unreachable code" New topic
Author

Question about unreachable code

Francisco Montes
Ranch Hand

Joined: Sep 30, 2009
Posts: 30
Hi javaranchers,

Sometimes the simplest pieces of code get my attention one way or another:



I would say that the line marked as "Last line" is unreachable. My logic is that there is no execution path that can go around the "return" statement. The finally section will execute and then we will leave the method (return). However the compiler does not look at it the same way.

Am i wrong? and if i´m not: how come that the compiler does not detect the last line as unreachable?

Thanks for you help!

Francisco


SCJP 1.6
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19067
    
  40

Francisco Montes wrote:
I would say that the line marked as "Last line" is unreachable. My logic is that there is no execution path that can go around the "return" statement. The finally section will execute and then we will leave the method (return). However the compiler does not look at it the same way.

Am i wrong? and if i´m not: how come that the compiler does not detect the last line as unreachable?


That is because... According to the compiler, it is reachable. Keep in mind that the Exception class is a super class of the RuntimeException class, which means that it is possible to catch unchecked exceptions. And since there is no way to check whether an unchecked exception is thrown, the compiler has to assume that the catch is reachable, and hence, what is after the try-catch is reachable.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

And the compiler is not always as smart as you would think:


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19067
    
  40

Wouter Oet wrote:And the compiler is not always as smart as you would think:



This one is intentional. The reachability checks around an "if" condition has been weaken, on purpose, to allow for conditional code.

Henry
Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

I don't follow. The compiler recognizes that the statement is unreachable because the byte code contains just the return statement. But why doesn't the compiler complain? Do you know an article about this phenomenon?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19067
    
  40

Wouter Oet wrote:I don't follow. The compiler recognizes that the statement is unreachable because the byte code contains just the return statement. But why doesn't the compiler complain? Do you know an article about this phenomenon?



See section 14.21 of the JLS.


And as mentioned, it doesn't complain to allow for conditional code.

Henry

Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19067
    
  40

Anyway... here is the relevant part of the JLS...

Java Language Specification wrote:One might expect the if statement to be handled in the following manner, but these are not the rules that the Java programming language actually uses:

* HYPOTHETICAL: An if-then statement can complete normally iff at least one of the following is true:
o The if-then statement is reachable and the condition expression is not a constant expression whose value is true.
o 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.

* HYPOTHETICAL: 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.

The actual rules for the if statement are as follows:

* ACTUAL: An if-then statement can complete normally iff it is reachable. The then-statement is reachable iff the if-then statement is reachable.
* ACTUAL: 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. The else-statement is reachable iff the if-then-else statement is reachable.

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 a significant impact on, and relationship to, binary compatibility (§13). 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. A change to the value of a flag is, therefore, not binary compatible with preexisting binaries (§13.4.9). (There are other reasons for such incompatibility as well, such as the use of constants in case labels in switch statements; see §13.4.9.)


Henry
Francisco Montes
Ranch Hand

Joined: Sep 30, 2009
Posts: 30
That is because... According to the compiler, it is reachable. Keep in mind that the Exception class is a super class of the RuntimeException class, which means that it is possible to catch unchecked exceptions. And since there is no way to check whether an unchecked exception is thrown, the compiler has to assume that the catch is reachable, and hence, what is after the try-catch is reachable.


I was kind of thinking this way too. I also agree that the compiler rules for detecting unreachable code may not be the same ones we think and we have to keep an eye on that.

Then again, i don´t think the SCJP exam will be so picky on this particular issue. At least, i hope so!

Thank you for all for your replies. :-)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question about unreachable code