[jdom-interest] TODO clone [eg]

Joseph Bowbeer jozart at csi.com
Sat Apr 14 12:57:04 PDT 2001


Dennis Sosnoski writes:

> I'd suggest that CloneNotSupportedException should have
> been a runtime exception in the first place, but such a
> suggestion would contravene the Doctrine of Java Infallability
> (or is that Gosling Infallability?). ;-)

Josh Bloch makes it very clear in "Effective Java" that Cloneable/clone is
screwed up.  Gosling was a member of the all-star cast of technical
reviewers (yours truly excluded).  Applying the law of Gosling
Transitivity ...

The primary flaws of Cloneable/clone are that Cloneable lacks a clone
method, and Objects's clone method is protected.  Also, as you say,
CloneNotSupportedException never should have been a checked exception.

By the way, there are some Java experts who take an even harder line such
as: "Don't ever use clone for anything."

The question for JDOM is whether clone is a requirement for subclasses or
not.  By declaring the CloneNotSupportedException in the superclass, we're
saying it's not a requirement and programmers should beware.  Another step
back would be to only provide a "protected" clone method in the superclass
and leave it up to subclasses to make it public if they want.

But if we can't back-off, we can't.


----- Original Message -----
From: "Dennis Sosnoski" <dms at sosnoski.com>
Sent: Saturday, April 14, 2001 11:01 AM
Subject: Re: [jdom-interest] TODO clone [eg]

I'd suggest that a better alternative for handling this is to continue to
assume clonability and throw an UnsupportedOperationException if a subclass
wants to prohibit cloning. The reason I suggest this is that attempting to
clone a non-clonable object will be a program structure error not normally
recoverable by alternate paths of execution; if someone wants to handle this
specially they can still catch the UnsupportedOperationException and do
whatever they want with it.

Using checked exceptions for program errors is generally not a great idea,
since it adds complexity to the code without any real benefits. I'd suggest
that CloneNotSupportedException should have been a runtime exception in
the first place, but such a suggestion would contravene the Doctrine of Java
Infallability (or is that Gosling Infallability?). ;-)

  - Dennis

Joseph Bowbeer wrote:

> Things TODO related to Cloneable.
>
> 1. CloneNotSupportedException. Our clone implementations have
> the following form:
>
>     public Object clone() {
>         try {
>             return super.clone();
>         }
>         catch (CloneNotSupportedException ex) {
>             // Can't happen
>         }
>     }
>
> I suggest that clone *not* catch CloneNotSupportedException -- except in
> final classes.  Instead, add the exception to clone's declaration, as
> follows:
>
>     public Object clone() throws CloneNotSupportedException {
>         return super.clone();
>     }
>
> This gives the subclasses final say about whether they are cloneable or
> not, and it forces the programmer to deal with the possibility that a
> subclass may not be cloneable.
>
> If we don't add the exception to the declaration, we should at least throw
> an InternalError as a sanity check:
>
>     public Object clone() {
>         try {
>             return super.clone();
>         }
>         catch (CloneNotSupportedException ex) {
>             throw new InternalError();
>         }
>     }








More information about the jdom-interest mailing list