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