Stephen, Do as you like. I do not want to fight on this. I think that my proposal is the best approach to (1) handle missing functionality in a way that will make life easier to users trying to run Java applications on classpath-based free vms amd (2) mimick the LinkageError usually expected in case of *unexpected* missing functionality (in contrast with *expected* missing functionality, indicated by UnsupportedOperationExcaprion). You seem to hold on your vision very strongly, and I am not ready to spend the effort to convince you.
Etienne On Mon, Sep 29, 2003 at 02:32:49PM +1000, Stephen Crawley wrote: > > Stephen Crawley wrote: > > > 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). > > This is equally satisfied by throwing UnsupportedOperationException > with a stereotypical message; e.g. > > throw new UnsupportedOperationException("not implemented yet - <details>") > > > > 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). > > I cannot see for the life of me where you are got this "different > semantics" idea from. The documentation for the exception defines its > semantics as: > > "Thrown to indicate that the requested operation is not supported." > > That is it. > > Our usage would be entirely consistent with this. An unimplemented > operation is (by definition) not supported because it is not implemented > yet!! Even the Collections Framework javadocs say (typically) that the > exception is thrown because (e.g.) "xyz is not supported by this > collection" without necessarily saying why. > > > See in my other message the example with JDK versions leading to > > LinkageError (not LinkageException extends UnsupportedOperationException). > > What is happening here is that you are calling a method that does not > exist in the older JDK. > > If we want this effect, we should NOT provide skeleton implementations > for missing methods at all. This would give a compilation error when > the application is compiled against Classpath, and a LinkageError if the > end user ran it the Classpath platform. > > (Not that I think this would be a good idea ... ) > > > > 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. > > Huh? A moment ago you were suggesting that the application programmer > should use properties containing Classpath version numbers and god-like > awareness of which versions of Classpath implemented which methods. > You were saying that this was easier to do than catching a NYIE. My > comment was addressing this. > > Now you seem to be saying (?) that the application programmer shouldn't > be writing his application to be aware of missing functionality at all?? > Fine ... but then you've taken my remarks out of context. > > -- Steve > > > > _______________________________________________ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath -- 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