Stephen Crawley wrote:
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.
There is no lockin, as NYIException (in)directly extends RuntimeException. I can catch RuntimeExceptions all day long without being locked into a particular implementation's subclass.
Application code that willfully uses internal classes of a runtime, be it sun.*, com.sun.*, com.ibm.*, or gnu.* is not portable anyway, so there is no harm done.
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.
Works equally well with exception handlers: Oops, we got a runtime exception trying method a, let's try method b. No problem there. ;)
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 :-)
You can't do this right now with Classpath anyway, as there is no way to know if a method is not implemented, or just does nothing on purpose. No harm done here either.
cheers, dalibor topic
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
