On Tue, Sep 21, 2010 at 1:50 PM, Casper Bang <[email protected]> wrote:
> > Besides, in my experience, Spring has as many haters as supporters, so > it's > > not really a shiny endorsement for runtime exceptions. > > It's true that Spring excels at producing stacktraces which, by > themselves, are vast enough to produce stackoverflows. But how that > serves as an argument for checked exceptions eludes me, that has more > to do with Spring being an uber-framework and being in love with type- > unsafe configurations. > The fact that all these exceptions are unchecked means that everyone ignores them at all levels, so they all bubble up to the top of the stack frame and they end up in your log. It's okay for unrecoverable errors to end there, that's the point of unchecked exceptions. But some of these exceptions are actually recoverable and if they had been declared checked, one of these layers would have dealt with them and done something sensitive instead of just ignoring it and letting it bubble up. And I wouldn't be surprised if sometimes, one checked exception that gets caught would prevent ten runtime exceptions from polluting your logs (just picking numbers at random, but you get the idea). Here is what most people fundamentally don't understand about checked exceptions: they are rare. Most of the exceptions are not recoverable, so they should be unchecked. But there is a small minority of exceptions that *are* recoverable and that the code should act upon, such as logging it, storing it in a database, presenting a dialog to the user, retrying, or whatever. Checked exceptions allow you to avoid crashing in situations where you should not be crashing. That's why they are useful. -- 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.
