If no user is allowed to catch this new error/exception, why are we going to the bother of creating it in the first place??
So that, when a user runs his application on top of a Free jvm using Classpath, he can identify clearly missing functionality (at run time, at least).
If the only reason for creating the new exception is as a documentation aid, then a better approach would be to throw UnsupportedOperationException
with a stereotypical error message and or stereotypical javadoc description.
No, because UnsupportedOperationException carries different semantics: it implies that the application was expecting some operation could be missing (as is the case with collections).
See in my other message the example with JDK versions leading to LinkageError (not LinkageException extends UnsupportedOperationException).
I think it is unreasonable to expect application developers to know which features where unimplemented / implemented in which versions of Classpath. IMO, this far more awkward than catching an exception.
Not at all. A normal Java programmer should expect nothing. He should simply try to run his application, and if a NYIE happens, he should try to either:
(1) implement the missing functionality (and contribute to classpath)
(2) try to circumvent the missing functionality by using equivalent, but implemented, classes/methods.
Etienne
-- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
