Re: NYIException

[Stephen Crawley]

Jeroen Frijters wrote:
> Andrew Haley wrote:
> > My only argument was against subclassing Error, because the Java
> > specification strongly implies that the only reasonable thing to do
> > when receiving an Error is issue a disgnostic and die.

I agree.  We should not be subclassing Error, or one of its descendents.
Error is reserved for things that an application has no hope in hell
of recovering from.

Sub-classing UnsupportedOperationException would be compatible with
existing JDK semantics and Java style.  However, it does tend to lockin
application code to a platform based on Classpath ... which is a bad
idea.  Even your idea of using a static to throw the NYIException
doesn't prevent this because the lockin happens when the application
refers to (e.g. catches) NYIException.

> > In the case of unimplemented Classpath methods, this seems rather 
> > extreme.

> Why? I don't see how you can reasonably continue given that an arbitrary
> functionality that the application depends on is missing.

Depending on what platform functionality is missing, it may be possible
for an application to be coded to "do it another way".  For example, a
product we're developing at work is designed to use the XML Schema
functionality.  But if the Java platform does not support XML Schemas, it
can fall back to using the simple XML.  

Alternatively, an application's error reporting may need to catch "not
yet implemented" exceptions to generate a specific diagnostic for the
end user.  For example, you may want to advise the user to upgrade their
Java platform ... in accordance with application release notes that they
probably didn't read properly in the first place :-)

However, an application developer should probably avoid doing this kind
of thing with a non-standard (Classpath specific) exception class unless
he/she is prepared to be locked into a Classpath-based Java platform. 

-- Steve