Multi-catch/final rethrow

[Stephen Colebourne]

While I'm sure many will welcome these additions, I must be clear that
I find the syntax approach used for final rethrow to be undesirable.
The change that the developer makes (adding 'final') is too subtle and
unconnected to the task at hand.

It also leads to some odd behaviour (assuming I've understood the spec):

public void process() {
  try {
    System.out.println("No exception thrown here...");
  } catch (final Exception ex) {
    throw ex;
  }
}

Here, we throw an exception without it appearing in the throws clause
of the method. I'm of the opinion that will be pretty confusing to
newcomers (and even some of us old-hands).

Note that I don't have a great alternative. I suspect a 'rethrow'
keyword would probably be best (dovetailed with the 'final' part for
obvious reasons). Given that we can't use a new keyword, perhaps the
'throws final' might work.

Stephen


On 4 May 2010 01:25,  <joe.darcy at oracle.com> wrote:
> Greetings,
>
> As alluded to as a possibility previously [1], I'm happy to announce
> that improved exception handling with multi-catch and final rethrow will
> be part of an upcoming JDK 7 build.  Improved exception handling is
> joining other Project Coin features implemented in the repository after
> successful experiences with a multi-catch implementation developed by
> Maurizio Cimadamore.
>
> Maurizio's work also revealed and corrected a flaw in the originally
> proposed static analysis for the set of exception that can be rethrown [2]:
>
>>  [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 subtype of one of the types in the declaration of the catch
>> parameter
>
> Consider a final rethrow statement as below where the dynamic class of a
> thrown exception differs from the static type (due to a cast in this case):
>
> class Neg04 {
>  static class A extends Exception {}
>  static class B extends Exception {}
>
>  void test(boolean b1, boolean b2) throws B {
>      try {
>          if (b1) {
>              throw new A();
>          } else if (b2) {
>              throw new B();
>          } else {
>              throw (Throwable)new Exception();
>          }
>      }
>      catch (A e) {}
>      catch (final Exception e) {
>          throw e;
>      }
>      catch (Throwable t) {}
>  }
> }
>
> The set of exceptions thrown by the try block is computed {A, B,
> Throwable}; therefore, the set of exceptions that can be rethrown is the
> set of exceptions from the try block:
>
> * minus A, handled by a previous catch clause, giving {B, Throwable}
> * minus Throwable since Throwable is not a subtype of one of the types
> declared for the catch parameter (just Exception in this case), leaving
> just {B}
>
> However, if an Exception is thrown from the try it should be caught in
> the "catch(final Exception e)" clause even if the exception is cast to
> Throwable since catch clauses work based on the runtime class of the
> exceptions being thrown.
>
> To address this, the third clause is changed to
>
>> - is a subtype/supertype of one of the types in the declaration of the
>> catch  parameter
>
> More formally, this clause covers computing a join over the set of
> thrown exceptions, eliminating subtypes.  In the example above
> {Throwable} is computed as the set of exceptions being throwable from
> the try block.  This is then intersected with the exceptions that can be
> caught by the try block, resulting in {Exception}, a properly sound result.
>
> Very general exception types being thrown by a try block would reduce
> the utility of multi-catch since only imprecise information would be
> available.  Fortunately, from analyzing the JDK sources, throwing a
> statically imprecise exception seems rare, indicating multi-catch with
> the amended specification should still be very be helpful in practice.
>
> Today the adventurous can apply a changest [3] to a copy of the JDK 7
> langtrools repository and build get a javac supporting this feature.
> Otherwise, the change will appear in promoted JDK 7 builds in due
> course. [4]
>
> -Joe
>
> [1] "Project Coin: Post-Devoxx Update, closures and exception handling,"
> http://blogs.sun.com/darcy/entry/projec_coin_post_devoxx_closures
>
> [2] "Improved Exception Handling for Java,"
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html
>
> [3] http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a6f2911a7c55
>
> [4] http://download.java.net/jdk7/binaries/
>
>