New protocol for disabling exception suppression

Bruce Chapman brucechapman at paradise.net.nz
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 oracle.com 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.

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