-
1. Re: CloneNoteSupportedException and *Info classes
juha Mar 8, 2002 12:21 PM (in response to squirest)yeah you can remove CNSE but don't use the copy constructor (or other constructors) in clone implementations.
-- Juha -
2. Re: CloneNoteSupportedException and *Info classes
squirest Mar 8, 2002 5:57 PM (in response to squirest)> yeah you can remove CNSE but don't use the copy
> constructor (or other constructors) in clone
> implementations.
>
> -- Juha
I spent some time with in the spec and javadoc. To be honest I'm baffled as to why people define copy constructors and use them in their clone() methods. The project we've inherited at work does this too. I wonder if I'm missing something...
Anyhow, because of the call to super.clone() I figure we should try/catch CNSE around the entire body of the *Info clone methods that aren't supposed to throw CNSE, do a *real* clone of thyself, and throw an Error in the catch block.
I'm away for the rest of the weekend so won't be looking at a computer till Sunday night.
Trevor -
3. Re: CloneNoteSupportedException and *Info classes
juha Mar 9, 2002 1:18 AM (in response to squirest)> To be honest I'm baffled as to why people define copy
> constructors and use them in their clone() methods.
> The project we've inherited at work does this too.
> I wonder if I'm missing something...
I think it is people with C++ background coming to Java. In C++ you defined copy constructors all over cause there was no clone, in Java you don't need a copy constructor cause you can implement Cloneable. Now we have a spec that mandates both clone and copy constructor. Ugh!. It is just plain ugly.
Besides, I think using a constructor in clone() implementation is against the contract defined in Object.clone()
Other thing that irks me is the way they declare runtime exceptions as part of the API signature all over the place. What an utterly pointless thing to do.
> Anyhow, because of the call to super.clone() I figure
> we should try/catch CNSE around the entire body of
> the *Info clone methods that aren't supposed to throw
> CNSE, do a *real* clone of thyself, and throw an
> Error in the catch block.
Yes that is correct.
-- Juha -
4. Re: CloneNoteSupportedException and *Info classes
adrian.brock Mar 13, 2002 7:27 AM (in response to squirest)As a programmer with a C++ background.
What is the problem with using a copy constructor
to override Object.clone() ?
I can see a problem if implements Cloneable is specified,
since that requires a field by field copy.
Regards,
Adrian -
5. Re: CloneNoteSupportedException and *Info classes
juha Mar 13, 2002 8:09 AM (in response to squirest)The issues are described here:
http://www.javaworld.com/javaworld/jw-01-1999/jw-01-object_p.html
two main reasons are it is against the contract specified in java.lang.Object.clone() and it makes implementing clone for subclasses more inconvenient.
-- Juha -
6. Re: CloneNoteSupportedException and *Info classes
adrian.brock Mar 13, 2002 8:29 AM (in response to squirest)I got it straightway as soon as you mentioned
subclass ;-)
The use of a constructor to copy an attribute is
a bit more subtle.
I'd better check my code...
Regards,
Adrian