Exactly. So, give programmers the option to say: Compiler, I know better. I want to ignore this checked exception (i.e. let it bubble up as normal, even though I don't officially "throws" it). Fixes everything.
On Sep 21, 11:37 pm, Cédric Beust ♔ <[email protected]> wrote: > 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.
