New protocol for disabling exception suppression

[brucechapman at paradise.net.nz]

Quoting Neal Gafter <neal at gafter.com>:

> ArrayList.add is used to add suppressed exceptions but that is not
> thread-safe.

True, but is that anything more than theoretical, given that for the
thread-unsafeness to be a problem, two threads would need access to the Throwable? 

While I am sure that situation could easily be contrived in a test, I can't see
it happening in practice, except where multiple threads are throwing the same
instance of an exception, and that is one of the cases where ignoring suppressed
exceptions would be expected.

On the other hand, I do have code that re-uses an exception (for flow control to
achieve backtrack in a large lookahead parsing situation), and maybe the ignore
suppressed functionality should be a little more obviously highlighted as very
appropriate (necessary) to this situation. Otherwise if that re-used exception
instance happens to pass through a t-w-r construct, it could keep having more
and more suppressed exceptions added to it, so in a long running app, none of
these suppressed exceptions can be garbage collected. This is not necessarily a
thread safety issue but is a potential 'memory leak'.

Bruce

> 
> On Sunday, April 3, 2011, Rémi Forax <forax at univ-mlv.fr> wrote:
> > On 04/03/2011 05:43 PM, Neal Gafter wrote:
> >> The mechanism for adding suppressed exceptions does not appear to be
> >> thread-safe.
> >
> > Why do you claim that ?
> > It's thread-safe like initCause is thread-safe.
> >
> >> Since this introduces a way in which exceptions used to
> >> be thread-safe but no longer are thread-safe, this might require
> >> significant nonlocal refactoring of existing code in order to use
> the
> >> new try-with-resources statement.
> >
> > Exceptions are still thread-safe.
> >
> > Rémi
> >
> >
> >
> 
>