New protocol for disabling exception suppression

[Rémi Forax]

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 [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.

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 
suppressed 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?

see above.
But anyway, the real question is why I can't create a Thowable that 
doesn't collect
suppressed exceptions. Is Throwable a second order citizen ?

> Bruce

Rémi