New protocol for disabling exception suppression

brucechapman at paradise.net.nz brucechapman at paradise.net.nz
Sun Apr 3 14:29:12 PDT 2011


Quoting Rémi Forax <forax at univ-mlv.fr>:

> On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote:
> > As part of the library support for the try-with-resources statement,
> > several API changes were made to Throwable including an addSuppressed
> > method to allow suppressed exceptions to be recorded. As previously
> > discussed on coin-dev [1], to support VM needs for reusable exception
> > objects, a protocol was devised to disable the suppression mechanism
> so
> > that a zero-length array would be returned from getSuppressed even if
> > addSuppressed was called with a valid argument. The mechanism was a
> bit
> > of a kludge, relying on an initial call to addSuppressed with a null
> > argument, and the design was called out as such. [2] I'm happy to
> report
> > the JSR 334 expert group has devised a more elegant protocol to
> disable
> > exception suppression: a new constructor is added to Throwable which
> > supports disabling suppression. The existing constructors of
> Throwable
> > always enable suppression and addSuppressed(null) now always throws a
> > NullPointerException. A few exception and error types in the platform
> > are allowed by behave as if their objects were created with
> suppression
> > disabled.
> >
> > The fix was recently pushed [3] and will appear in a future JDK 7
> build.
> >
> > -Joe
> 
> Reading the corresponding javadoc,
> I've found that the constructor is protected. In my opinon, it should
> be public. All the other constructors are public, you can instantiate
> a Throwable but if you want a Throwable that don't store
> suppressed exceptions, you have to subclass it.
> I don't understand the rational of this decision.

This makes it non trivial to ignore suppressed exceptions - which is (IMHO) a
good thing. If you have extraordinary circumstances where it is necessary to
ignore suppressed exceptions (such as VM Out of memory) then this restriction
will not be onerous. If it is onerous, then probably you should not be trying to
ignore supressed exceptions.

Do you have a use case that justifies ignoring supressed exceptions for an
existing subclass of Throwable that cannot be simply subclassed in order to
achieve ignoring suppressed exceptions?

Bruce

> 
> > [1]
> http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html
> > [2]
> >
> http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920
> > [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea
> 
> Rémi
> 
> 
>  




More information about the coin-dev mailing list