Maybe what this discussion needs is some real-world anecdotes of checked vs unchecked exceptions in production environments and how they helped or not to save the day.
Alexey 2001 Honda CBR600F4i (CCS) 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net ________________________________ From: Peter Becker <peter.becker...@gmail.com> To: javaposse@googlegroups.com Sent: Tuesday, August 18, 2009 6:13:54 AM Subject: [The Java Posse] Re: How do YOU handle Exceptions? I still believe that the main reason people hate checked exceptions is that they have been used badly. But I don't really like them either, I just dislike runtime exceptions more ;-) The reason for that is that they hide things I might want to know about when using an API. No one reads documentation well enough, the enforcement checked exceptions give you is quite useful -- at least given the context of Java. And I don't buy into the "just unit test" argument, things like SQLException and IOException rarely happen in test environments unless the test was designed to test just that -- it is the exceptional case you don't expect that scares me. What I would really like to see is a meet/or/disjunction/union operator in the type system, with a case-like construct to resolve the resulting types. Scala has two things that are halfway there (Either, case classes), but neither is the full monty. Peter phil swenson wrote: > there is a reason no other language ever written has checked > exceptions - checked exceptions are a bad idea. > > On my first java project back in 1999 I remember adding in a checked > exception to a utility class. It has effects on hundreds of classes > and 1000s of method calls. I then decided it was more trouble than it > was worth and switched everything to runtime exceptions. Worked > brilliantly. > > Checked exceptions almost always degenerate into "throws exception" on > 100s to 1000s of methods in your project. They simply don't scale, > one small change can ripple through an entire project. They also lead > to try{blahblah}catch(Exception e}{} (exception hiding). They lead to > logging the exception multiple times (catch, log, rethrow), giant > method signatures, exception wrapping, and other harmful practices. > > The correct (IMO) way to handle it is to let the exception bubble up > to the top level thread and handle it there, whether it's present to > the user, log, and/or cancel a transaction. Exceptions almost never > can be recovered from and people are almost always fooling themselves > if they think they can. I think 95+% of the time exceptions are from > bugs, not from recoverable situations. People try to build hugely > fault tolerant systems and they end up hiding bugs. > > In the rare case that you want to handle an exception at a lower > level, do it. But you certainly don't want this to be the default > behavior, it's the EXCEPTIONAL case. :) > > > > On Aug 17, 9:10 pm, Michael Neale <michael.ne...@gmail.com> wrote: > >> What do people think of the scala approach of no checked exceptions - >> even checked exceptions are not treated specially by the constructor >> (personally, I like it). >> >> On Aug 18, 12:55 pm, Christian Catchpole <christ...@catchpole.net> >> wrote: >> >> >>> No, i just let that go up. I really try to avoid the declare as null >>> then set thingy. >>> >>> On Aug 18, 12:03 pm, Casper Bang <casper.b...@gmail.com> wrote: >>> >>>> You neglect to handle the checked exception declared by >>>> prepareStatement no? >>>> >>>> PreparedStatement stmt = null; >>>> try{ >>>> stmt = connection.prepareStatement(sql); >>>> final ResultSet rs = stmt.executeQuery(); >>>> try{ >>>> while (rs.next()){ >>>> // Stuff... >>>> { >>>> } >>>> finally{ >>>> rs.close(); >>>> }} >>>> >>>> catch(SQLException e){ >>>> // Logging...} >>>> >>>> finally{ >>>> try{ >>>> stmt.close(); >>>> } >>>> catch(SQLException whoTheFuckCares){ >>>> }; >>>> >>>> } >>>> >>>> Really, how many other ways are there to do it I wonder now? (Apart >>>> from wrapping certain things, like the last try-catch clause in some >>>> general purpose "closer util"?). >>>> >>>> /Casper >>>> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---