New protocol for disabling exception suppression

[Rémi Forax]

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.

>
> -Joe

Rémi