Per Bothner wrote: > 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.
Ah I see where you are coming from. If an application wants to run under a variety of VM's and also wants to deal with Classpath's limitations, it is not going to be able to compile against a host VM that doesn't have this Classpath specific exception type. If the application uses the RuntimeException type in its catch clause then it will catch genuine RuntimeExceptions too and will have to try and distinguish them (which means reflectively querying its type for the Classpath specific exception type). Using any existing exception type that could never normally be thrown by these methods when they are implemented, solves this problem. And UnsupportedOperationException is as semantically close as you'll get to the right kind of exception. Note that an optional method that is not yet implemented (how could you tell? :) ) should always throw UnsupportedOperationException, not NYIException. David Holmes _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath