New protocol for disabling exception suppression

[Dr Heinz M. Kabutz]

>> 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.
>   
Hi Rémi,

by moving the functionality to the constructor, where it probably 
belongs, it means that in order for subclasses to be able to turn off 
the ability to add suppressed exceptions, every single exception in the 
history of Java needs to have a new constructor (or set of constructors) 
that take the boolean.  In a constructor, I cannot call my 
super-super-class' constructor directly.  This means Exception needs 
this constructor, and IOException and FileNotFoundException, plus of 
course all the exceptions that people might have added to their own 
projects.

Kind regards from Crete, where spring has sprung :-)

Heinz