Re: NotYetImplementedError [Was: NYIException]

[Stephen Crawley]

> Stephen Crawley wrote:
> > If no user is allowed to catch this new error/exception, why are we going
> > to the bother of creating it in the first place??
> 
> So that, when a user runs his application on top of a Free jvm using 
> Classpath, he can identify clearly missing functionality (at run time, 
> at least).

This is equally satisfied by throwing UnsupportedOperationException
with a stereotypical message; e.g.

  throw new UnsupportedOperationException("not implemented yet - <details>")

> > If the only reason for creating the new exception is as a documentation 
> > aid, then a better approach would be to throw UnsupportedOperationException
> > with a stereotypical error message and or stereotypical javadoc description.
> 
> No, because UnsupportedOperationException carries different semantics: 
> it implies that the application was expecting some operation could be 
> missing (as is the case with collections).

I cannot see for the life of me where you are got this "different
semantics" idea from.  The documentation for the exception defines its
semantics as:

  "Thrown to indicate that the requested operation is not supported."

That is it.  

Our usage would be entirely consistent with this.  An unimplemented
operation is (by definition) not supported because it is not implemented
yet!!  Even the Collections Framework javadocs say (typically) that the
exception is thrown because (e.g.) "xyz is not supported by this
collection" without necessarily saying why.

> See in my other message the example with JDK versions leading to 
> LinkageError (not LinkageException extends UnsupportedOperationException).

What is happening here is that you are calling a method that does not
exist in the older JDK. 

If we want this effect, we should NOT provide skeleton implementations
for missing methods at all.  This would give a compilation error when
the application is compiled against Classpath, and a LinkageError if the
end user ran it the Classpath platform.

(Not that I think this would be a good idea ... )

> > I think it is unreasonable to expect application developers to know
> > which features where unimplemented / implemented in which versions
> > of Classpath.  IMO, this far more awkward than catching an exception.
> 
> Not at all.  A normal Java programmer should expect nothing.  He should 
> simply try to run his application, and if a NYIE happens, he should try 
> to either:
> (1) implement the missing functionality (and contribute to classpath)
> (2) try to circumvent the missing functionality by using equivalent, but 
> implemented, classes/methods.

Huh?  A moment ago you were suggesting that the application programmer
should use properties containing Classpath version numbers and god-like 
awareness of which versions of Classpath implemented which methods.
You were saying that this was easier to do than catching a NYIE.  My
comment was addressing this.

Now you seem to be saying (?) that the application programmer shouldn't
be writing his application to be aware of missing functionality at all??
Fine ... but then you've taken my remarks out of context. 

-- Steve