New protocol for disabling exception suppression
forax at univ-mlv.fr
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.
More information about the coin-dev