Re: Checked Exceptions

I don't believe the problem with checked exceptions is that you can't
easily ignore them. Rather, what I don't like about them is that often
they force you to deal with exceptions too early.

                                                   For example,
consider this scenario:

class A implements interface B. B declares a void doSomething();
method.
To implement B, A uses a method in a library C which can throw a
LibraryCException.
Now A cannot alter the signature of doSomething() to throw a C-
specific exception. But A cannot catch it either, because it doesn't
know how to deal with it: should it cancel the operation? Should it
retry? Should it report failure to the user, and how? etc. So what
does A do? Wrap it in a RuntimeException and rethrow it. The net
effect is that A behaves the same as if LibraryCException were
unchecked, but it includes more boilerplate code (the try-catch needed
to wrap the exception) and obfuscates the exception itself with a
layer of wrapping, making it harder to deal with it at the upper
levels, should the need arise. I see this sort of scenario happening
very often in the kinds of applications I work on (multi-layer J2EE
apps).