> 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. And if a bean setup is erroneous in Spring, then how is a checked exception going to help? 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 reckon that the rethrow feature is also going to help here, rather than having to successively wrap in new runtime exceptions when crossing layers, attributing to a longer, but none the wiser, stack trace. -- 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.
