New protocol for disabling exception suppression
forax at univ-mlv.fr
Sun Apr 3 14:42:00 PDT 2011
On 04/03/2011 11:29 PM, brucechapman at paradise.net.nz wrote:
> 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 , to support VM needs for reusable exception
>>> objects, a protocol was devised to disable the suppression mechanism
>>> that a zero-length array would be returned from getSuppressed even if
>>> addSuppressed was called with a valid argument. The mechanism was a
>>> of a kludge, relying on an initial call to addSuppressed with a null
>>> argument, and the design was called out as such.  I'm happy to
>>> the JSR 334 expert group has devised a more elegant protocol to
>>> exception suppression: a new constructor is added to Throwable which
>>> supports disabling suppression. The existing constructors of
>>> 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
>>> The fix was recently pushed  and will appear in a future JDK 7
>> 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.
It's not that extraordinary if you write language runtimes :)
I use to use exceptions to jump back in the control flow when by
example you jump from a compiled code (in bytecode) back to
the interpreter (of the language).
In that case, I don't want to create a subclass if I can create a Throwable
once and reuse it.
But if I want to be able to reuse it, it should not be able to collect
> 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?
But anyway, the real question is why I can't create a Thowable that
suppressed exceptions. Is Throwable a second order citizen ?
More information about the coin-dev