classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NotYetImplementedError [Was: NYIException]


From: Etienne Gagnon
Subject: NotYetImplementedError [Was: NYIException]
Date: Sun, 28 Sep 2003 22:19:43 -0400
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4) Gecko/20030908 Debian/1.4-4

Hi all,

I personally think that a Java application should not try to discover the JVM/library version through an akward usage of exceptions/errors.

If an application wants to adapt to some version of the above, it should use System.getProperty() and test for a specific jvm/class-library version. If an application fails to do so, and if this application calls an unimplemented method, I think that the best course of action is for an error to be thrown, so that execution fails with a beautiful stack trace, informing the application developer of the problem.

So, my proposal is:
(1) Throw NotYetImplementedError extends Error (or LinkageError?)
(2) Document clearly that users of Classpath SHOULD NOT catch this exception, but use System.getProperty("gnu.classpath.version") instead. (3) Document, in the VM interface, that such property should be set, of course.

Etienne


David Holmes wrote:
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
address@hidden
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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]