Proposal: Improved Exception Handling for Java

[Neal Gafter]

 Improved Exception Handling for Java*AUTHOR(S):*Neal M Gafter
*OVERVIEW* FEATURE SUMMARY:

   - Catching multiple exception types: A single catch clause can now catch
   more than one exception types, enabling a series of otherwise identical
   catch clauses to be written as a single catch clause.
   - Improved checking for rethrown exceptions:  Previously, rethrowing an
   exception was treated as throwing the type of the catch parameter.  Now,
   when a catch parameter is declared final, rethrowing the exception is known
   statically to throw only those checked exception types that were thrown in
   the try block, are a subtype of the catch parameter type, and not caught in
   preceding catch clauses.

MAJOR ADVANTAGE:

   - Catching multiple exception types: Simplifies a commonly appearing
   pattern of redundant code.
   - Improved checking for rethrown exceptions: This improvement makes it
   possible to add a try-catch statement around a block of code to intercept,
   process, and rethrow an exception without affecting the statically
   determined set of exceptions thrown from the code.

 MAJOR BENEFIT:Greatly simplifies writing and maintaining code where
intercepting or processing exceptions is common.
 MAJOR DISADVANTAGE:One-time implementation cost for adding the features to
the compiler.  Longer language specification in describing the behavior.
ALTERNATIVES:

   - These behaviors are approximated currently by writing a series of
   identical catch clauses.  During maintenance, the set of catch clauses must
   be modified so that it continues to match the set of exceptions statically
   thrown in the try block.  With the proposed changes, the catch block can be
   written to catch a supertype of the set of exceptions to be intercepted,
   resulting in fewer catch clauses and fewer changes required when the try
   block evolves.

EXAMPLES SIMPLE EXAMPLE:try {
    doWork(file);
} catch (final IOException|SQLException ex) {
    logger.log(ex);
*    throw ex;*
}
 ADVANCED EXAMPLE:*Show advanced usage(s) of the feature.*
DETAILS SPECIFICATION:
The grammar of Java is extended to allow a series of exception types,
separated by the "OR" operator symbol, to be used in a catch clause:

*CatchClause:*
 catch ( *CatchFormalParameter* ) *Block
**CatchFormalParameter:
 VariableModifiers CatchType VariableDeclaratorId
CatchType:
 DisjunctionType
DisjunctionType:
 Type
 Type | DisjunctionType**
*

The type system is affected as follows: For the purpose of type checking, a
catch parameter declared with a disjunction has type lub(t1, t2, ...) [JLS3
15.12.2.5<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#301183>].
For the purpose of exception checking [JLS3
11.2<http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2>],
a throw statement [JLS3
11.2.2<http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2.2>]
that rethrows a final catch parameter is treated as throwing precisely those
exception types that

   - the try block can throw,
   - no previous catch clause handles, and
   - is a subtye of one of the types in the declaration of the catch
   parameter


To avoid the need to add support for general disjunctive types, but leaving
open the possibility of a future extension along these lines, a catch
parameter whose type has more than one disjunct is required to be declared *
final*.
 COMPILATION:A catch clause is currently compiled (before this change) to an
entry in an exception table that specifies the type of the exception and the
address of the code for the catch body. To generate code for this new
construct, the compiler would generate an entry in the exception table for
each type in the exception parameter's list of types.
 TESTING:The feature can be tested by compiling and running programs that
exercise the feature.
 LIBRARY SUPPORT:No.
 REFLECTIVE APIS:No reflective API changes are required.
 OTHER CHANGES:It would be desireable, at the same time that this change is
made, to update the non-public Tree API that can be used with APT to express
the syntax extension.
 MIGRATION:None required.  However, it would be easy to detect a series of
otherwise identical catch clauses for different types and collapse them to a
single catch clause.
 COMPATIBILITY BREAKING CHANGES:Joe Darcy observes that the following
program compiles before this change, but not after:

*try {*
*   throw new DaughterOfFoo();*
* } catch (final Foo exception) {*
*   try {*
*      throw exception; // used to throw Foo, now throws DaughterOfFoo*
*   } **catch (SonOfFoo anotherException) { // Reachable?*
*   }*
* }*

However

   - This breakage is compile-time-only; already-compiled programs continue
   to behave as before
   - This kind of breakage is very unlikely to occur in practice, and
   - The broken code was likely wrong before, as it attempts to catch
   exceptions that simply cannot occur.

 EXISTING PROGRAMS:Except as above, none.
 REFERENCES EXISTING BUGS:No existing bugs that I am aware of.
 URL FOR PROTOTYPE (optional):An implementation of disjunctive catch
parameters, but without special handling for final catch parameters:

   - http://www.javac.info/

See also

   - *Catching Multiple Exception Types:*
   http://www.javac.info/Multicatch.html
   - *Improved Checking for Rethrown Exceptions:*
   http://www.javac.info/Rethrown.html