New protocol for disabling exception suppression

[brucechapman at paradise.net.nz]

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

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

Yes in a way it is second order. If it is a Throwable (rather than a subclass)
then you are saying it is not an Error, and it is not an Exception, and it is
not a RuntimeException! So what is it?

Maybe there should be some new top level form of Throwable for these reusable
flow control situations which we both have. maybe a checked form, and an
unchecked form of it?  Those two could then be made to do the right thing,
possibly even not having a stacktrace! If it was checked tho' I'd want to
subclass it so that my throws clauses used my own name, not
'ReusableFlowControlException' or whatever it might be called.

Bruce


> 
> > Bruce
> 
> Rémi
> 
>