RE: NYIException

[David Holmes]

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