Re: NYIException

[Dalibor Topic]

Hi Per,

Per Bothner wrote:
> We discussed this in March, and there was agreement that we
> should use use UnsupportedOperationException.
>
> See http://gcc.gnu.org/ml/java/2003-03/msg00016.html

I agree there was an agreement that something should be done, and the 
practice of returning null/nothing was 'evil', but I didn't parse the 
discussion as specifically nailing down UnsupportedOperationException or 
UnsupportedOperationException(String reason) as the particular 
implementation to pick.

When your proposal came up again on the Classpath mailing list after the 
LinuxTag meeting, it was ammended by me and Andy Walter to the 
NYIException with a verbose 'please contribute' message. Again, no 
decision was made in favor or against it. See 
http://mail.gnu.org/archive/html/classpath/2003-07/msg00053.html

So it's back at the table, in my opinion, and I hope this time around we 
can agree on a concrete implementation ;) I'd like to point out my 
arguments in favor of a specific NotYetImplementedException:

a) it would be easy to write a tool that walks over classpath's rt.jar, 
loads the classes using Class.forName, uses reflection to check which 
methods are not implemented yet, and produces simple todo lists.

b) It makes it clear that a method is not implemented, whereas an 
UnsupportedOperationException already has a different meaning: it means 
that a collection class doesn't support an optional operation. In my 
opinion, there is nothing optional about non-implementing a method. ;) 
So having NotYetImplementedException extend 
UnsupportedOperationException would be semantically confusing, as it 
mixes what's allowed by the API with what we know is wrong, but didn't 
get around to fix yet. The behaviour for code that catches 
UnsupportedOperationException would be weird, too, as the code would 
silently change its behaviou as Classpath improves, and the 
unimplemented method is implemented. That's not something I'd want when 
I program against an otherwise stable API.

c) It comes with a beautiful motivational message. It tried to motivate 
the people who want to run their code on top of classpath, and it 
doesn't work, to try to fix it.

d) It can be easily extended to cover additional information if 
necessary, like API version:
{
public static API extends Object {
private API(){};
}
public static final API 1_0 = new API();
public static final API 1_1 = new API();
...

private static final String help = "Fix GNU Classpath now!";

private API api;
private String reason;

public NotYetImplementedException(String reason, API api) {
        this.reason = reason;
        this.api = api;
}

public NotYetImplementedException(String reason) {
        this.reason = reason;
}
}

cheers,
dalibor topic