Seems to me that this is a RuntimeException then. Only an application that is being written for Classpath will be able to take alternative action if core functionality is missing. Any other application will just have to throw up its hands.
On the other hand, if the exception is UnsupportedOperationException then it is possible for a portable application to try an alternative approach - which may work.
If the exception is a new class, then that is not possible.
If it doesn't catch it, then nothing is lost.
It should *NOT* be a subclass of an existing exception type that has well defined semantics and is likely to be caught in general applications - like UnsupportedOperationException. I agree with Jeroen that not being implemented when it should be, is quite distinct from not supporting an optional operation.
The latter is true, but the former does not follow. I think creating a new non-portable sub-class is solving a non-existent problem.
But more important is throwing *some* exception. We *must* fix the
current situation where unimplemented methods silently do nothing
or return null.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
