New protocol for disabling exception suppression

Bruce Chapman brucechapman at
Wed Apr 6 03:14:45 PDT 2011

On 5/04/2011 10:27 p.m., David Holmes wrote:
> Bruce Chapman said the following on 04/05/11 20:00:
>> On 5/04/2011 2:41 p.m., joe.darcy at wrote:
>>> I could see an argument for adding analogous protected constructors to
>>> java.lang.{Exception, RuntimeException, Error} to allow non-platform
>> Without analogous constructors I don't think it will be possible to 
>> make a checked exception with suppressed disabled.
> Well Throwable is a checked exception.  Without analogous constructors 
> users won't be able to make instances of any existing exception types 
> (checked or unchecked) with suppression disabled, but ...
>> So long as users can make their own checked and unchecked exceptions 
>> with suppression disabled that should be enough.
> ... the intent was never to provide users with such a facility, but 
> simply to ensure that the actions of the VM were allowed under the 
> specification.

Yes, I understand the history, but for cases where a single exception 
instance is being used multiple times (both Remi and I have given 
example use cases), if those were unwound through a t-w-r, then we could 
keep getting more and more suppressed exceptions added, each time it was 
used and the close() failed. Unusual? yes, but possible. The right way 
to make a reusable (flow control) exception is to disable suppressed 
exceptions - that ability needs to be provided.

> David
>> Bruce
>>> exceptions to control this behavior.  However, just as not all 
>>> exception
>>> types have a full complement of the existing four Throwable
>>> constructors, very, very few exceptions types need a constructor that
>>> allows suppression to be disabled.  In particular, there are no 
>>> plans to
>>> go through and retrofit a bunch of these constructors into the majority
>>> of the exception types defined in the platform.
>>> -Joe

More information about the coin-dev mailing list