Opps, somehow dropped the javaposse group post on this. ---------- Forwarded message ---------- From: phil swenson <[email protected]> Date: 2011/3/23 Subject: Re: [The Java Posse] How to deal with CheckedExceptions To: Cédric Beust ♔ <[email protected]>
Thanks for the Lazy comment. You can handle Exceptions even if they are RuntimeExceptions (just like you do in every language ever created other than Java). Usually you want to let them bubble up, so it's very annoying to have to deal with them at every level up the stack. No one is arguing against ever handling exceptions. See this: http://www.artima.com/intv/handcuffs.html or this: http://www.mindview.net/Etc/Discussions/CheckedExceptions or this: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 I'm reading Robert C. Martin<http://www.amazon.com/Robert-C.-Martin/e/B000APG87E/ref=sr_ntt_srch_lnk_1?qid=1300922689&sr=8-1>'s (Uncle Bob) "Clean Code" right now and I actually was surprised almost every code example he gives says "throws Exception". But he does go on a rant against CheckedExceptions in the book so I guess he's just in the "throws Exception" camp as a solution to the problem. I also just found this snippet for what Bruce Eckel advocates (from http://www.ibm.com/developerworks/library/j-jtp05254.html#resources): Bruce Eckel, author of *Thinking in Java* (see Resources<http://www.ibm.com/developerworks/library/j-jtp05254.html#resources>), says that after years of using the Java language, he has come to the conclusion that checked exceptions were a mistake -- an experiment that should be declared a failure. Eckel advocates making all exceptions unchecked, and offers the class in Listing 2 as a means for turning checked exceptions into unchecked ones while preserving the ability to catch specific types of exceptions as they are propagated up the stack (see his article in the Resources<http://www.ibm.com/developerworks/library/j-jtp05254.html#resources>section for an explanation of how it can be used): class ExceptionAdapter extends RuntimeException { private final String stackTrace; public Exception originalException; public ExceptionAdapter(Exception e) { super(e.toString()); originalException = e; StringWriter sw = new StringWriter(); e.printStackTrace(new PrintWriter(sw)); stackTrace = sw.toString(); } public void printStackTrace() { printStackTrace(System.err); } public void printStackTrace(java.io.PrintStream s) { synchronized(s) { s.print(getClass().getName() + ": "); s.print(stackTrace); } } public void printStackTrace(java.io.PrintWriter s) { synchronized(s) { s.print(getClass().getName() + ": "); s.print(stackTrace); } } public void rethrow() { throw originalException; } } 2011/3/23 Cédric Beust ♔ <[email protected]> > > > On Wed, Mar 23, 2011 at 2:43 PM, phil swenson <[email protected]>wrote: > >> I never thought I'd see anything useful on an OSGi blog, but today I saw >> this: >> >> http://www.osgi.org/blog/2011/03/exception-hygiene.html >> >> So if you accept that CheckedExceptions are a bad idea... read the >> comments on this post. There is a debate as to how to handle the atrocity >> that the CheckedException. There are two approaches that are debated: >> >> 1) >> void foo() { >> try { >> bar(); >> } catch( Exception e) { >> throw new RuntimeException(e); >> } >> } >> >> 2) >> void foo() throws Exception { >> bar(); >> } >> >> I used to be in the #1 camp. But after reading the thread, I'm thinking >> that just putting throws Exception everywhere might be easier/more >> pragmatic. It's uglier, but it does make the stack dump more readable I >> think. >> > > I'm quite baffled by the justifications here. All this hacking just so the > stack dump is more readable? Is that really what you care the most about? > > I care about my code being robust, which means handling errors in a > sensible way. Sometimes, it means catching them and/or wrapping them, other > times it means declaring them in my throws clause and letting the code above > deal with what happened. This should be the only deciding factor in how you > want to handle checked exceptions. > > What you (and the author of the blog post) are advocating is basically "I'm > too lazy to handle errors so I'm just going to ignore them". The author of > the post even has the nerve to say "It's amazing how readable your code > becomes". Well, yes, if you start ignoring error cases, your code becomes > much simpler. > > Instead of just putting a blanket ban on all checked exceptions, he would > have been better off trying to understand which ones need to be checked and > which ones should be unchecked. All he's done with his fork is making the > servlet less robust. > > Checked exceptions are a good idea and an indispensable component of robust > software, but they are easy to misuse. > > -- > Cédric > > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
