8 Answers
8

If you've read the item about cloning in my book, especially if you read between the lines, you will know that I think clone is deeply broken. [...] It's a shame that Cloneable is broken, but it happens.

You may read more discussion on the topic in his book Effective Java 2nd Edition, Item 11: Override clone judiciously. He recommends instead to use a copy constructor or copy factory.

He went on to write pages of pages on how, if you feel you must, you should implement clone. But he closed with this:

Is all this complexities really necessary? Rarely. If you extend a class that implements Cloneable, you have little choice but to implement a well-behaved clone method. Otherwise, you are better off providing alternative means of object copying, or simply not providing the capability.

The emphasis was his, not mine.

Since you made it clear that you have little choice but to implement clone, here's what you can do in this case: make sure that MyObject extends java.lang.Object implements java.lang.Cloneable. If that's the case, then you can guarantee that you will NEVER catch a CloneNotSupportedException. Throwing AssertionError as some have suggested seems reasonable, but you can also add a comment that explains why the catch block will never be entered in this particular case.

Alternatively, as others have also suggested, you can perhaps implement clone without calling super.clone.

Unfortunately, the project is already written around using the clone method, otherwise I would absolutely not use it. I entirely agree with you that Java's implementation of clone is fakakta.
–
CugaFeb 24 '10 at 14:49

3

If a class and all its superclasses call super.clone() within their clone methods, a subclass will generally only have to override clone() if it adds new fields whose contents would need to be cloned. If any superclass uses new rather than super.clone(), then all subclasses must override clone() whether or not they add any new fields.
–
supercatJun 26 '12 at 15:15

There are two cases in which the CloneNotSupportedException will be thrown:

The class being cloned does not implemented Cloneable (assuming that the actual cloning eventually defers to Object's clone method). If the class you are writing this method in implements Cloneable, this will never happen (since any subclasses will inherit it appropriately).

The exception is explicitly thrown by an implementation - this is the recommended way to prevent clonability in a subclass when the superclass is Cloneable.

The latter case cannot occur in your class (as you're directly calling the superclass' method in the try block, even if invoked from a subclass calling super.clone()) and the former should not since your class clearly should implement Cloneable.

Basically, you should log the error for sure, but in this particular instance it will only happen if you mess up your class' definition. Thus treat it like a checked version of NullPointerException (or similar) - it will never be thrown if your code is functional.

In other situations you would need to be prepared for this eventuality - there is no guarantee that a given object is cloneable, so when catching the exception you should take appropriate action depending on this condition (continue with the existing object, take an alternative cloning strategy e.g. serialise-deserialise, throw an IllegalParameterException if your method requires the parameter by cloneable, etc. etc.).

Edit: Though overall I should point out that yes, clone() really is difficult to implement correctly and difficult for callers to know whether the return value will be what they want, doubly so when you consider deep vs shallow clones. It's often better just to avoid the whole thing entirely and use another mechanism.

If an object exposes a public cloning method, any derived object which did not support it would violate the Liskov Substitution Principle. If a cloning method is protected, I would think that it would be better to shadow it with something other than a method returning the proper type, to prevent a subclass from even trying to call super.clone().
–
supercatJul 5 '12 at 15:25

So you've just written it to the file system and have read the object back. Okay, is this the best method to handle clone? Can anyone from SO community comment on this approach? I guess this unnecessarily ties Cloning and Serialization - two entirely different concepts. I will wait to see what others have to say about this.
–
Saurabh PatilNov 8 '14 at 23:09