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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
