PROPOSAL: Unchecked Exceptions as Subclasses of Checked Exceptions

[Alan Snyder]

Derek,

You have raised an interesting point.

The programs that I have written do not suffer from this problem. They
already contain the required exception handlers (which are legitimate),
and my goal is to avoid having to add additional clauses to those existing
(and legitimate) exception handlers.

But, as you point out, there is a language specification issue here. If an
exception handler catches a checked exception that is not final, the
compiler can no longer assume that the exception will not be thrown,
because a method could throw an instance of an unchecked subclass of that
exception.

I looked through the JLS to see where this compiler error comes from.

Section 14.20 says:

	It is a compile-time error if a catch clause catches checked exception
type E1 but there exists no checked exception type E2 such that all of
the following hold:

	...

	The try block corresponding to the catch clause can throw E2

My proposal would be to change "checked exception type E2" to "exception
type E2". The effect of this change would be to make most exception
handlers legal, unless E1 was declared final.

I would also propose that the current compiler error message be changed to
a warning message in cases where the previously illegal exception handler
is now legal. Perhaps the warning could be suppressed when E1 is known to
have an unchecked subclass.

Some people might not like this change. I actually think this message
should have been a warning instead of an error from the beginning. When
code is under development and in flux, I often find myself having to
comment out exception handlers and try blocks to keep the compiler happy
while I am experimenting with code changes. This is busy work that does
nothing to make my programs more reliable.

Furthermore, while some might argue it is misleading to have an exception
handler that can never catch an exception, perhaps I want it there because
I think that a future version of the code or of the code I am calling
might starting throwing this exception.

  Alan




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

Furthermore, I in many ways CAN'T add a catch clause for the base type in
outside code, as your proposal suggests is its goal:

Foo getStuff() {
    try {
        return getFoo2();
    } catch (FooDoesNotExistException e) {  // This is a compiler error.
Exception is never thrown in try block.
        // handle exception here
    }
}

The only time it would be legal for me to add a catch clause for the base
type would be if there was another method also being called in the same
try..catch block which DID throw the base exception.