New protocol for disabling exception suppression

[Neal Gafter]

On Mon, Apr 4, 2011 at 7:41 PM, <joe.darcy at oracle.com> wrote:

>
>
> 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.
>

Your response is a paraphrase of the illogical argument "don't do that,
because what if everybody else did".

It feels very strange for the API to declare that this feature is reserved
for subclasses but forbidden on the base class.  You might think it a shame
that Throwable has a public constructor to begin with, but a public API is
not a nice place to air such grievances.

Just saying.