New protocol for disabling exception suppression

Rémi Forax forax at
Mon Apr 4 11:33:31 PDT 2011

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 

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


More information about the coin-dev mailing list