Is it really that bad? Most of the common exceptions shouldn't be there at all, for example NullPointerException, ClassCastException and ArrayStoreException are all just signs of a broken type system. Some of the Errors seem unavoidable, but with the Exceptions I still prefer the idea of actually managing them.
Note that one of the most important patterns for me is chained exceptions. Somehow it took until JDK 1.4 until they got introduced and even then not completely. But by chaining exceptions you can keep the number of exceptions in each layer down and you also provide encapsulation. In the end it comes down to a lot of different factors, including personal taste. But I am still not willing to dismiss checked exceptions as a generally bad idea. Peter Viktor Klang wrote: > The problem I feel is that an Exception should denote an EXCEPTIONAL > occurrence, and be able to list all things that can happen is just > plain impossible. > So switching to a fully checked exceptions would mean that every > method signature should mandatory include stuff like: > > public void foo(Bar bar) throws TheSkyIsFallingException, > HellFrozeOverException, ShitInShitOutException > > > etc. > > While you could say that all these exceptions are EntropyExceptions > you could say: > > public void foo(Bar bar) throws EntropyException > > But why stop at that? > > You might as well generalize it into > > public void foo(Bar bar) throws Exception > > And if you know that every method can throw an exception, you might as > well say that > > public void foo(Bar bar) implicit throws Exception > > And, then you basically have RuntimeException > > On Tue, Aug 18, 2009 at 12:13 PM, Peter Becker <peter.becker.de > <http://peter.becker.de>@gmail.com <http://gmail.com>> wrote: > > > 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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> > >> 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 <[email protected] > <mailto:[email protected]>> 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 > >>>> > > > > > > > > > > > > > -- > Viktor Klang > > Rogue Scala-head > > Blog: klangism.blogspot.com <http://klangism.blogspot.com> > Twttr: viktorklang > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
