New protocol for disabling exception suppression

joe.darcy at oracle.com joe.darcy at oracle.com
Mon Apr 4 19:41:34 PDT 2011



On 4/4/2011 11:33 AM, Rémi Forax wrote:
> On 04/04/2011 07:52 PM, Joe Darcy wrote:
>> Hi Remi.
>>
>> Rémi Forax wrote:
>>> [...]
>>>
>>>>>
>>>>> Reading the corresponding javadoc,
>>>>> I've found that the constructor is protected. 
>>>>
>>>> That was intentional.
>>>
>>> I know. You aren't a student anymore.
>>
>> That doesn't mean I don't make mistakes from time to time ;-)
>>
>>> But I think this intention is not well grounded.
>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Disabling suppression is a niche capability.  It does not need to 
>>>> be made as easy to use as other capabilities of Throwable.  If a 
>>>> need arises to make the new constructor public, that can be done 
>>>> compatibly in a future release.
>>>
>>> Why not now ?
>>> Again, why Throwable has to be different from one of it's subclass.
>>>
>>
>> This capability does not need to be used widely; in particular, I 
>> don't think it needs to be used on instantiations of Throwable 
>> objects.  Any subclass of Throwable can disable exceptions so the 
>> only behavioral difference between having this constructor public and 
>> protected is that that objects where getClass == Throwable cannot 
>> have exception suppression disabled.
>
> Yes, this is a small corner case and yes perhaps never someone will 
> create a Throwable with exception suppression disabled.
> But those who design Throwable had thunk that create a Throwable with 
> new make sense, so for completeness
> one should be able to create a Throwable with exception suppression 
> disabled.
>
> By declaring the constructor as protected you add a special rule, you 
> increase the entropy of the Throwable API
> without, in my opinion, any benefit.
>

I could see an argument for adding analogous protected constructors to 
java.lang.{Exception, RuntimeException, Error} to allow non-platform 
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