tag:blogger.com,1999:blog-36773632.post5475523924864609000..comments2023-12-19T08:40:05.062-05:00Comments on Java Evangelist John Yeary: Try...Catch...Finally Puzzle Part IIJohn Yearyhttp://www.blogger.com/profile/00461192445071361043noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-36773632.post-23654733556822191882011-10-14T07:06:16.362-05:002011-10-14T07:06:16.362-05:00The Java Language Specification (JLS) is very spec...The Java Language Specification (JLS) is very specific about the behavior. <br /><br />Fundamentally, since we are discarding the Exception(s) being thrown at a point where we should handle them, there are no breadcrumbs to tell us what happened. <br /><br />In this trivial example, the method continues executing and exits normally.<br /><br />If this were used in the context of a larger application, the implications would be huge in terms of trying to find out why the application crashed.John Yearyhttps://www.blogger.com/profile/00461192445071361043noreply@blogger.comtag:blogger.com,1999:blog-36773632.post-7917003819658848452011-10-14T04:53:52.114-05:002011-10-14T04:53:52.114-05:00This implies that your application could be brough...This implies that your application could be brought to an abrupt halt without any indication as to why.<br /><br />Your finally block in your main method has no code in it which should cause it to end abruptly and you have an unhandledException Handler ready in case something untoward happens deeper into your app. <br />However code in your main finally block causes something like OutOfMemoryError to be thrown in the current Thread and bang, application dies with no indication as to why.<br /><br />So try {} finally {} is not as safe as one would expect and may have implications for try resources in JDK 7 leading to potential leaks.Andy Baileyhttps://www.blogger.com/profile/09630023617691486651noreply@blogger.comtag:blogger.com,1999:blog-36773632.post-44394540221548227892011-10-13T05:20:06.945-05:002011-10-13T05:20:06.945-05:00These are great responses. I love it when there ar...These are great responses. I love it when there are links to other great materials. <br /><br />Bruce does a great job in <b>"Thinking in Java"</b>. He even keeps the material up to date.John Yearyhttps://www.blogger.com/profile/00461192445071361043noreply@blogger.comtag:blogger.com,1999:blog-36773632.post-82913016346809411782011-10-13T02:34:49.494-05:002011-10-13T02:34:49.494-05:00This behavior was described in Eckel's book so...This behavior was described in Eckel's book some 110 years ago:<br /><br />http://linuxtopia.org/online_books/programming_books/thinking_in_java/TIJ311_014.htm<br /><br />Konrad Ciborowski<br />Kraków, PolandKonrad Ciborowskihttps://www.blogger.com/profile/14477208832750334215noreply@blogger.comtag:blogger.com,1999:blog-36773632.post-45662283609243850642011-10-12T21:42:08.235-05:002011-10-12T21:42:08.235-05:00The trick is in the finally block. There is a retu...The trick is in the finally block. There is a return statement which short circuits the exception processing. The compiler recognizes that there is no way that an exception is thrown so it allows you to do anything you want. The scary part is that run time exceptions are discarded too. I have included the appropriate corner case remarks from the Java Language Standard (JLS) and the actual requirement.<br /><br /><br />http://java.sun.com/docs/books/jls/third_edition/html/statements.html<br /><br /><b>§14.20.2 Execution of try-catch-finally</b><br />...<br /><br />If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and reason R is discarded).<br /><br />...John Yearyhttps://www.blogger.com/profile/00461192445071361043noreply@blogger.comtag:blogger.com,1999:blog-36773632.post-26953970735205548502011-10-12T10:12:27.215-05:002011-10-12T10:12:27.215-05:00To complete the answer.
You would expect the seco...To complete the answer.<br /><br />You would expect the second NPE to be handled after the main method returns however the return statement causes the currently running Thread to need to exit (hence the return causing the private Thread.exit() method to execute immediately rather than closing the JVM down).Andy Baileyhttps://www.blogger.com/profile/09630023617691486651noreply@blogger.comtag:blogger.com,1999:blog-36773632.post-78161481566386591802011-10-12T09:30:35.603-05:002011-10-12T09:30:35.603-05:00Based on what we learned from the last JUG...
I ...Based on what we learned from the last JUG... <br /><br />I believe that both will print out nothing..<br /><br />The finally at least in JDK 7 will consume the exceptions..<br /><br />JamesJames C Bragghttps://www.blogger.com/profile/16635260064181688029noreply@blogger.com