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 :-)