Re: NotYetImplementedError [Was: NYIException]
Just a little note: On Mon, Sep 29, 2003 at 02:32:49PM +1000, Stephen Crawley wrote: > 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: The semantic difference comes from the inheritance hierarchy. java.lang.Exception is documented as: The class Exception and its subclasses are a form of Throwable that indicates conditions that a reasonable application might want to catch. A reasonable application should not expect a "standard" method not to be yet implemented, IMHO. 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
Re: NotYetImplementedError [Was: NYIException]
Etienne Gagnon wrote:
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.
I'd agree with Etienne, I think his proposal is the best so far, but if
Stephen and Per don't like it at all, let it be
UnsupportedOperationException.
I'd like to keep the 'please contribute to Classpath if this missing
functionality' message though, so let's mandate using
throw new UnsupportedOperationException("not yet implemented: " + reason
+ gnu.classpath.Recruiting.CONTRIBUTE_PLEASE_MESSAGE);
if that's o.k. with everyone.
cheers,
dalibor topic
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: NotYetImplementedError [Was: NYIException]
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 - ")
>
> > > 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
RE: NotYetImplementedError [Was: NYIException]
Etienne Gagnon wrote:
> 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.
I fully support this proposal and I like the idea of extending
LinkageError.
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: NotYetImplementedError [Was: NYIException]
> 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 - ")
> > 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
Re: NotYetImplementedError [Was: NYIException]
> I personally think that a Java application should not try to discover
> the JVM/library version through an akward usage of exceptions/errors.
I personally disagree that it is awkward.
> Many applications (including SableCC, I think) do things like:
>
> try ...
> catch(Exception e)
> {...}
>
> In such context, a missing method is definitely *not* an exception.
Catching Exception or RuntimeException is usually a good indication that
the application's exception handling is broken. In my experience, there
are only two cases where an ordinary application should catch Exception
or RuntimeException:
* so that you can report exception that would otherwise disappear
into the aether; (e.g. in a non-main thread), or
* so that you can record an exception in the application's error log.
Anything else and the application risks squashing serious exceptions and
doing inappropriate recovery.
In the context above, an unimplemented method is no more or less an
Exception than NullPointerException or UnsupportedOperationException.
In each case, the exception is probably an application error, but the
application could conceivably recover and continue. Thus, if we were
to invent a new exception/error, a subtype of RuntimeException would
be the most appropriate.
-- Steve
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
RE: NotYetImplementedError [Was: NYIException]
> FYI: There are interesting "standard" system properties > that could be used for this: > > java.specification.version 0.06 > java.specification.vendor Gnu > java.specification.nameClasspath No - specifications come from Sun only. The only thing Classpath can define (or rather the VM using Classpath) is: java.vm.version Java Virtual Machine implementation version java.vm.vendor Java Virtual Machine implementation vendor java.vm.name Java Virtual Machine implementation name Classpath will have to define its own property strings for anything else. But it seems to me that even if version numbers could be used the basic scenario will be as follows: 1. Application developer writes app 2. Developer runs against Classpath and discovers unimplemented methods through some exception being thrown 3. Developer changes app to protect calls to such methods with a classpath version check. So there will still need to be an exception mechanism to discover the methods that are not implemented. Further anytime a new Classpath version comes out the developer has to check all of the now implemented methods and update the version number for any still not implemented. I can't see people making that effort. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NotYetImplementedError [Was: NYIException]
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). 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
Re: NotYetImplementedError [Was: NYIException]
David Holmes wrote:
I'm not so sure this is about actual version information but more
about not yet implemented methods in a VM/library that purports to
support the version of the API that includes that method. Classpath is
in the unfortunate state of supporting different versions of API's
depending on which class you are looking at, so what version
information would the system property return?
It should report Classpath's version (e.g. 0.06).
I do really think that an application should not use the exception
mechanism to discover the class library version (of course, classpath
0.06 != specific sun jdk version, but this is still a version).
Throwing a error seems to be the right thing to do.
Many applications (including SableCC, I think) do things like:
try ...
catch(Exception e)
{...}
In such context, a missing method is definitely *not* an exception.
If a programmer knows that his application will be running on an
incomplete/inconsistent class library, he should definitely use a system
property to make the appropriate control-flow choices. In the *worst*
ugly hack case, he could do a catch(NotYetImplementedError e), but this
should definitely be avoided.
Throwing an error and aborting the application is the right thing to do
for 99,9% of Java applications. If an application was coded expecting
some method to be present, then an error should happen. This is already
the case with Sun's JDK, e.g.:
An application is written for JDK 1.4. Application is run on JDK 1.1.
A 1.4-specific method is called => LinkageError is thrown.
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
Re: NotYetImplementedError [Was: NYIException]
FYI: There are interesting "standard" system properties that could be used for this: java.specification.version 0.06 java.specification.vendor Gnu java.specification.nameClasspath ;-) 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
Re: NotYetImplementedError [Was: NYIException]
> 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.
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??
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.
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.
-- Steve
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: NotYetImplementedError [Was: NYIException]
David Holmes wrote: I personally think that a Java application should not try to discover the JVM/library version through an akward usage of exceptions/errors. I'm not so sure this is about actual version information but more about not yet implemented methods in a VM/library that purports to support the version of the API that includes that method. Classpath is in the unfortunate state of supporting different versions of API's depending on which class you are looking at, so what version information would the system property return? The one of Classpath, as that's the only one it knows for sure. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NotYetImplementedError [Was: NYIException]
> I personally think that a Java application should not try > to discover the JVM/library version through an akward usage of > exceptions/errors. I'm not so sure this is about actual version information but more about not yet implemented methods in a VM/library that purports to support the version of the API that includes that method. Classpath is in the unfortunate state of supporting different versions of API's depending on which class you are looking at, so what version information would the system property return? David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
NotYetImplementedError [Was: NYIException]
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
[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
