I totally abhor checked exceptions, although the concept has a lot going for it they just cause too many problems.
they: - increase coupling between units - create test paths that are often challenging to get coverage for - invite API users to swallow them or log them at an inappropriate time (often several times) - encourage a poor coding style where an exception is used as an alternate return path for a condition that isn't all that exceptional - complicate the control flow that has to be understood when reading a piece of code - add boilerplate (as though Java needed more of *that*) - are quite possibly the reason why lambdas couldn't be finished in time for Java 7 The typical use-case for me is that when I call a function that may throw an exception, I usually can't respond to it in any sane fashion until I'm 4 or 5 levels higher up the call-stack. Often, the higher-level function will then aggregate several exceptions from lower levels in the stack and make a "retry/error recovery/continue regardless/inform the user" decision. Declaring exceptions on the intermediate levels just clutters up my code base, and offers too much potential for error with nothing to show in return. 2010/9/21 Cédric Beust ♔ <[email protected]> > > > On Tue, Sep 21, 2010 at 2:26 PM, Casper Bang <[email protected]>wrote: > >> > Checked exceptions allow you to avoid crashing in situations where you >> > should not be crashing. That's why they are useful. >> >> Sure, that's all fine in theory - but in practice nobody get this >> boundary right when doing API design; that's a historical fact. > > > Agreed. Nobody said it was easy, and the JDK is a good example of how *not* > to use checked exceptions correctly in many cases. > > But should we give up on the concept just because it's hard to get right? > > It's very much like saying "handling all these error return codes is > difficult so I'll just ignore them all". > > >> And if a bean setup is erroneous in Spring, then how is a checked >> exception >> going to help? > > > A bean set up error is probably not recoverable in most cases, so a runtime > exception is justified in this case. What is not acceptable is Spring's > blanket refusal to use checked exceptions anywhere. > > >> Do you really want to wrap every layer in each their >> own exception, or pollute signatures with long exception lists? >> >> Spring produces stacktraces the size of Pluto, not because of >> unchecked exceptions, but because it lacks post- and pre-conditions - >> sanity checks for when to give up. > > > I don't think the difference between pre/post-conditions and runtime > exceptions is significant enough to make a huge difference in this case > since they are both runtime events. It's a bit like choosing to let your > application blow up on an NPE or throwing the NPE yourself after testing the > variable against null. > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- 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.
