RFE Pre-review: Support for cloning exceptions

[Martin Buchholz]

On Wed, Dec 2, 2015 at 1:32 AM, Peter Levart <peter.levart at gmail.com> wrote:

>
> In short, I think exceptions are a special hierarchy with special use
> pattern in which clone() would not present a practical problem that
> generally arises in other objects that are meant to change state
> independently from their creation.
>

Java is supposed to be a high reliability platform and introducing new
exotic failure modes isn't something we should be doing.  My work at Google
prejudices me - it seems half the work we do is trying to track down rare
bugs we can't reproduce, or happen once every cpu-year.

If you add "implements Cloneable" then people will call protected nullary
clone().  You haven't made it public, but it can (and will!) be called from
subclasses and their packages.  I see you were careful to copy the
suppressedExceptions field in your static clone, but callers of the "real"
clone will produce two Throwables that share a single ArrayList, which is
not thread safe.

I'm sure there's code out there that reasonably assumes that if something
is Cloneable, then it has a public clone() method, and will try to invoke
that via reflection.

I see that if an existing subclass of Throwable implemented Cloneable,
there would be no way (short of Unsafe) for its clone method to do a proper
copy of suppressedExceptions.  In the future, if Throwable were to
implement Cloneable, then more subclasses are likely to add a public
clone() method (to "support" cloning) and that will only do a proper copy
of suppressedExceptions if you do the copying in nullary Throwable.clone()
instead of in static clone.

Sadly, making Throwable Cloneable is exceedingly subtle and I think we will
regret it (as we do the design of Cloneable itself).