ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Implementing the Clonable interface in a task
Date Mon, 12 Aug 2002 17:54:57 GMT

----- Original Message -----
From: <>
To: "Ant Developers List" <>
Sent: Monday, August 12, 2002 10:32 AM
Subject: Implementing the Clonable interface in a task

> If a task (a class extending implements the
> Clonable interface how should it deal with subclasses whose clone method
> throw a CloneNotSupportedException?
> The following code snipt from Thinking in Java page 1032 shows a try catch
> block around the call to super.clone().
> public Object clone() {
>       Thing4 o = null;
>       try {
>             o=(Thing4)super.clone();
>       } catch (CloneNotSupportedException e) {
>             System.err.println("Thing4 can't clone");
>       }
>       //bla bla bla
> }

but that breaks the rule of 'throw exceptions up till you know where to
really catch them'. What do you return from this method if you cant clone?
the original? null? Better to keep throwing and let the stuff upstream
handle it.

I dont know of any cloning that takes place.

> Someone out there may be wondering why I am looking to clone an Ant task.
> I am creating two tasks that use the CVS task by composition.  This same
> approach is taken by the CvsTagDiff task.  The two classes I am writting
> also have some shared functionality that should be moved off into a
> class.  The complication is that the utility class must have a configured
> CVS object to do its job.  The simplest way to configure the CVS instance
> used by the utility is to simply clone the CVS instance within the client
> class and pass it to the utility class's constructor or as an argument to
> any static method.

How about teasing the CVS configuration into a self contained object? Or
pass a non-cloned reference in?

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message