PROPOSAL: Unchecked Exceptions as Subclasses of Checked Exceptions (original) (raw)

Alan Snyder javalists at cbfiddle.com
Thu Mar 26 11:57:54 PDT 2009

[This is a revised proposal based on the previous comments. It includes a use case.]

Unchecked Exceptions as Subclasses of Checked Exceptions

AUTHOR: Alan Snyder

OVERVIEW

FEATURE SUMMARY:

This proposal would allow the definition of an unchecked exception class that extends a checked exception class.

MAJOR ADVANTAGE:

Unchecked exception classes are useful when an exception must be thrown through an existing interface that does not declare any checked exceptions or an appropriate checked exception. If one can define both an unchecked exception class and a corresponding checked exception class such that the unchecked exception class extends the checked exception class, then the unchecked exception will be caught by a try statement that catches the checked exception.

MAJOR BENEFIT:

Programs do not have to explictly catch both the unchecked and checked exceptions. Most developers need only be aware of the checked exception. The potential mistake of not catching the unchecked exception is avoided.

MAJOR DISADVANTAGE:

A new marker interface (or equivalent) must be defined and the definition of unchecked exceptions changed.

ALTERNATIVES:

The alternative is to always explicitly catch both the unchecked and checked exceptions, which introduces a likely source of programming errors.

EXAMPLE:

This proposal uses a marker interface as an alternative way (besides subclassing RuntimeException and Error) of indicating that an exception class defines an unchecked exception.

The following would define a checked exception and an unchecked exception that extends the checked exception:

public class TheCheckedException
    extends Exception {};

public class TheUncheckedException
    extends TheCheckedException
    implements UncheckedException {};

The following is a sketch of a possible use case.

Consider a program A that reads and writes data using file I/O, with the presumption that there are good reasons not to read all of the data into memory. The program catches IOException in appropriate places so that it can recover gracefully should an I/O error occur.

Now suppose that program A wants to use existing library B to manipulate this data, but library B does not know about files. Instead, assume that B uses some more generic interface to access data, such as List. Note that the List get() method does not define a checked exception for data access failure. Thus, in the bridge code that allows the file data to be accessed via the List interface, program A would have to wrap any IOExceptions in a RuntimeException. Suppose it defines a new class, UncheckedIOException, for this purpose.

In current Java, program A would need to augment its exception handlers to handle both IOException and UncheckedIOException.

Using this proposal, UncheckedIOException could be an unchecked exception and also subclass from IOException, so that the exception handlers for IOException would catch UncheckedIOException as well.

DETAILS

SPECIFICATION:

The JLS would be changed to add one more way to define an unchecked exception.

JLS 11.2 The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes.

would become

The unchecked exceptions classes are the class RuntimeException and its subclasses, the class Error and its subclasses, and those subclasses of Exception that implement the UncheckedException interface. All other exception classes are checked exception classes.

JLS 11.5 The subclasses of Exception other than RuntimeException are all checked exception classes.

would become

The subclasses of Exception other than RuntimeException are checked exception classes, unless they implement the UncheckedException interface.

The marker interface UncheckedException would have to be defined in some java package, with java.lang being the obvious choice.

COMPILATION:

The compiler would have to be extended to recognize the new category of unchecked exceptions.

I'm not aware of other changes.

COMPATIBILITY

The major compatibility issue arises from the introduction of a new name in the class name space. That could potentially cause a program to fail to compile if it imported a class with the name UncheckedException using a wild card import statement.

There could also be programs that examine the class hierarchy at runtime or using a compiler API that would not recognize some exception classes as being unchecked. I imagine these would mostly be language tools, which one would expect to need revision for a new version of Java.

More information about the coin-dev mailing list