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).
Say you've caught a RuntimeException e:
if (e.getClass().getName().equals("gnu.classpath.NYIException")) {
// do the classpath dance
}can compile just fine against any not-gnu-classpath-using VM. You could use reflection, too, but there is no need here.
cheers, dalibor topic
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
