PROPOSAL: Unchecked Exceptions as Subclasses of Checked Exceptions

[Alan Snyder]

[Oops... wrong subject line on the previous message.]

Derek,

I will respond to your two points in separate messages.

You raise the issue that this proposal will weaken the guarantee in
current Java that requires the caller of a method to consider (catch or
declare in its own signature) the exceptions thrown by the methods that it
calls.

I do not see how this would happen. Any method that declares a checked
exception will require an exception handler or declaration, as in current
Java. Any method that throws an unchecked exception will not, as in
current Java.

Your example method getFoo2() does not declare that it throws a checked
exception. Thus, as in current Java, there is no guarantee that the caller
will consider the possibility of an exception being thrown by this method.
If you want callers of your API to be forced to consider a possible
exceptional condition, you must declare the methods to throw checked
exceptions. There is no change here.

Yes, it is true that someone could write a method that throws an unchecked
exception when it would have been more appropriate to throw the superclass
checked exception. That does not seem any different than throwing a
Runtime exception when a checked exception would have been more
appropriate. It is bad programming, for which there is no help from the
compiler.

Anyway, I'm sure that you wouldn't put a method like that in your API, and
I'll bet you're not likely to do it by mistake (which is where compiler
support would be relevant).

  Alan




On Mar 28, 2009, at 5:43 PM, Derek Foster wrote:

Although I appreciate what you are trying to do with this proposal, and I
have certainly been inconvenienced by the problem that you are trying to
solve, I am also very concerned with unintended consequences of your
proposal. Your proposal describes its intended effect, and it certainly
seems able to solve that use case, but does not seem to really delve into
other impacts of this change in behavior which might be less positive.

One of the reasons I typically use checked exceptions in programs is to
ensure that all callers of an API must consider and handle the various
error conditions that can occur. Thus if I have a method like:

void getFoo() throws FooDoesNotExistException;

I can be assured that anyone who calls getFoo() will be forced to consider
what to do if the Foo object does not exist. They may choose to ignore the
error condition, but at least they will have been forced to consider it
(by adding a 'catch' clause somewhere in the program for it or one of its
supertypes). This is one of the most important reasons to use checked
exceptions in the first place: They allow the compiler to do what amounts
to essentially a compile-time proof that all checked exceptions will
eventually be handled by someone.

Your proposal seems to have the potential to break this guarantee, so that
someone could have a method like:

void getFoo2(); // throws UncheckedSubtypeOfFooDoesNotExistException;

then if I call it in my code:

Foo getStuff() {
    return getFoo2();
}

I am never forced to add a catch clause for FooDoesNotExistException
anywhere.