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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
