wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Finally return causing unreachable statements Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Finally return causing unreachable statements" Watch "Finally return causing unreachable statements" New topic
Author

Finally return causing unreachable statements

Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Does anybody know why javac allows this code to compile, even when the return statements in the try and catch blocks are unreachable?


In contrast, if you have something like this:

The compiler complains that // Unreachable is unreachable.

Thanks!


All code in my posts, unless a source is explicitly mentioned, is my own.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1752
    
    7

Because section 14.20.2 of the JLS says so (third edition):


If execution of the try block completes abruptly for any other reason R, then the finally block is executed. Then there is a choice:
If the finally block completes normally, then the try statement completes abruptly for reason R.
If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and reason R is discarded).


According to section 14.1 (and 14.17) a return statement always completes abruptly.

Still, if you compile the first code sample with the Sun compiler and specify the -Xlint option (or -Xlint:finally) you should get a compiler warning something like: "warning: [finally] finally clause cannot complete normally". If anything that should be enough of an indication that the return-from-finally approach is rarely, if ever, appropiate.

Also, it might be worth noting that by returning from within a finally block you can inadvertantly discard unhandled exceptions thrown from within the try block.
[ December 30, 2008: Message edited by: Jelle Klap ]

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
kshitij dogra
Ranch Hand

Joined: Dec 28, 2008
Posts: 39
Hi Ruben.

what actually happening is, in code 1

- finally is always executed after try, (except when System.exit(0) is called). So, before the try block can return the value, finally is executed .

code 2
- You have mentioned the return statement after finally. As I told you in the previous case the call has to go to the return statement of the finally, and then the method call stack will collapse. This would cause the 3rd return statement , never to be executed......

Hence the error.


SCJP 5.0 - 100%
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Originally posted by Jelle Klap:
Also, it might be worth noting that, aside from masking the return value of the try-block, any uncaught run-time exceptions that are thrown from inside the try-block are also discarded in this scenario.

Thanks for your answer, Jelle.
If I understand it correctly, the quote above means that the return statement in the finally block renders any potential runtime exceptions arising in the try block inconsequential (the method will return the expression in the finally block's return statement, and the program will proceed as if no runtime exception had been thrown, or as it had been caught in an empty catch block.)

I assume the same would be the case if any runtime exceptions are thrown in the catch block.

Very interesting.
[ December 30, 2008: Message edited by: Ruben Soto ]
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Originally posted by kshitij dogra:
Hi Ruben.

what actually happening is, in code 1

- finally is always executed after try, (except when System.exit(0) is called). So, before the try block can return the value, finally is executed .

code 2
- You have mentioned the return statement after finally. As I told you in the previous case the call has to go to the return statement of the finally, and then the method call stack will collapse. This would cause the 3rd return statement , never to be executed......

Hence the error.

Thanks, kshitij. I understand what is going on. I was just wondering why the first case wouldn't cause a compiler error, but like Jelle mentioned it can cause a warning if javac is executed with the appropriate flag.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1752
    
    7

Originally posted by Ruben Soto:

Thanks for your answer, Jelle.
If I understand it correctly, the quote above means that the return statement in the finally block renders any potential runtime exceptions arising in the try or catch blocks inconsequential (the method will return the expression in the finally block's return statement, and the program will proceed as if no runtime exception had been thrown, or as it had been caught in an empty catch block.)

I assume the same would be the case if any runtime exceptions are thrown in the catch block.

Very interesting.


Well, I edited my previous post because I only mentioned RuntimeExceptions, and it really applies to all unhandled Throwables.
And yes, if a RuntimeException was to occur inside a catch block in such a situation it would be discarded.

Try this, contrived, example:



Compile and run, then disable the return from testDiscardThrowable's finally block and compile and run again.
[ December 30, 2008: Message edited by: Jelle Klap ]
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Great post, Jelle. Thanks a lot, it's clear now!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Finally return causing unreachable statements
 
Similar Threads
Exception
Un reachable statement (Sorry for posting the same topic second time...)
unreachable code in 'finally'
Finally abrupt return
Unreachable, return in finally or catch