Re: NYIException
> > Jeroen Frijters wrote: > > > > > I'm certainly not throwing in the towel ;-) I think it should be an > > > error, but I can live with NYIException being an Exception, what I > > > cannot accept is (ab)using UnsupportedOperationException. > > > > I still don't see any real problem with UnsupportedOperationException, > > but I don't care that much. > > I also can't see anything wrong with using UnsupportedOperationException. > Could someone who thinks this would be abuse, please explain WHY they > think so ... preferably with supporting evidence from the Sun javadocs. Please forget I wrote this. I'm happy for the discussion to die ... as per Mark's email. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
> Jeroen Frijters wrote: > > > I'm certainly not throwing in the towel ;-) I think it should be an > > error, but I can live with NYIException being an Exception, what I > > cannot accept is (ab)using UnsupportedOperationException. > > I still don't see any real problem with UnsupportedOperationException, > but I don't care that much. I also can't see anything wrong with using UnsupportedOperationException. Could someone who thinks this would be abuse, please explain WHY they think so ... preferably with supporting evidence from the Sun javadocs. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Jeroen Frijters wrote: I'm certainly not throwing in the towel ;-) I think it should be an error, but I can live with NYIException being an Exception, what I cannot accept is (ab)using UnsupportedOperationException. I still don't see any real problem with UnsupportedOperationException, but I don't care that much. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
On Mon, 2003-09-29 at 09:25, Andrew Haley wrote: > Out of interest (and please forgive me if this has already been > discussed at length) why have dummy methods at all? Wouldn't it be > better to have a compile time failure for unimplemented methods? If you go this route what happens when code which was compiled elsewhere is run using the classpath libraries? lurkingly yours, -emile > Andrew. > > > > ___ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath > ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Andy Walter writes: > Hi Andrew, > > On Monday 29 September 2003 19:40, Andrew Haley wrote: > > Throwing an appropriate message will help, of course, but one of > > the advantages of gcj is that you can pre-link and you know you > > won't get runtime linkage errors -- the linker has resolved > > everything. Having dummy implementations loses this gcj > > advantage. > > Dummy implementations that do nothing are a really bad thing, I > agree. But a dummy implementation that either returns with the > correct result or throws a NYIException makes it clear to the user > what had happened. > > Currently, we have those dummy methods anyway - and can't get rid > of them, because some methods are partly, but not completely, > implemented. With a new Exception class, the gcj linker could stop > with an error message when such a method is instantiated and > thrown. Err, no. Linking happens at link time; throwing happens at runtime! But this gives me an idea. I can parse the class at compile time, and if I see any references to a method that throws such an exception I can warn the user about it. That would be *much* better. It wouldn't be complete because there might be partly implemented subclasses that aren't directly referenced, but it would be better than nothing. > If we abuse any existing JDK Exeption for it, this would not be > possible. True. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Emile Snyder writes: > On Mon, 2003-09-29 at 09:25, Andrew Haley wrote: > > Out of interest (and please forgive me if this has already been > > discussed at length) why have dummy methods at all? Wouldn't it be > > better to have a compile time failure for unimplemented methods? > > If you go this route what happens when code which was compiled elsewhere > is run using the classpath libraries? I guess you'd get a LinkageError? Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Andrew, On Monday 29 September 2003 19:40, Andrew Haley wrote: > Throwing an appropriate message will help, of course, but one of the > advantages of gcj is that you can pre-link and you know you won't get > runtime linkage errors -- the linker has resolved everything. Having > dummy implementations loses this gcj advantage. Dummy implementations that do nothing are a really bad thing, I agree. But a dummy implementation that either returns with the correct result or throws a NYIException makes it clear to the user what had happened. Currently, we have those dummy methods anyway - and can't get rid of them, because some methods are partly, but not completely, implemented. With a new Exception class, the gcj linker could stop with an error message when such a method is instantiated and thrown. If we abuse any existing JDK Exeption for it, this would not be possible. Cheers, Andy. -- aicas GmbH Haid-und-Neu-Straße 18 * 76131 Karlsruhe http://www.aicas.com Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Dalibor Topic writes: > Jeroen Frijters wrote: > > Andrew Haley wrote: > > > >>Out of interest (and please forgive me if this has already been > >>discussed at length) why have dummy methods at all? Wouldn't it be > >>better to have a compile time failure for unimplemented methods? > > > > > > I think so, but sometimes (e.g. when implementing interfaces or > > extending abstract classes), you're required to provide the methods, but > > I agree that not having the unimplemented method is the cleanest > > solution. > > On the other hand, you can start writing the docs & 'prototypes' > for a class without having to fully implement everything. Depends > on the point of view, I guess. > > And of course, there is the 'you can at least compile it using > classpath, even if you can't run it' aspect, that plays a big role > for debian and similar 'free software buildable by free tools' > efforts, afaik. I see. While this is okay for the Classpath development process, I don't think it's best for gcj. We've already had some confusion where users compile code with gcj and it fails to run. Throwing an appropriate message will help, of course, but one of the advantages of gcj is that you can pre-link and you know you won't get runtime linkage errors -- the linker has resolved everything. Having dummy implementations loses this gcj advantage. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Jeroen Frijters wrote: Andrew Haley wrote: Out of interest (and please forgive me if this has already been discussed at length) why have dummy methods at all? Wouldn't it be better to have a compile time failure for unimplemented methods? I think so, but sometimes (e.g. when implementing interfaces or extending abstract classes), you're required to provide the methods, but I agree that not having the unimplemented method is the cleanest solution. On the other hand, you can start writing the docs & 'prototypes' for a class without having to fully implement everything. Depends on the point of view, I guess. And of course, there is the 'you can at least compile it using classpath, even if you can't run it' aspect, that plays a big role for debian and similar 'free software buildable by free tools' efforts, afaik. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Andrew Haley wrote:
Out of interest (and please forgive me if this has already been
discussed at length) why have dummy methods at all? Wouldn't it be
better to have a compile time failure for unimplemented methods?
One reason is that it makes it possible to compile code against
Classpath that includes references to methods that Classpath hasn't yet
implemented. This code might run just fine for the purpose you need it,
because the unimplemented calls are in a codepath that you aren't taking.
Another reason to have NYIError[1] is that in some cases a method may be
implemented for some cases and not others, depending on its arguments.
For example, a method might not have the correct behavior implemented as
fallback for when one of its arguments is null, or might only work for
particular subclasses of the class it's supposed to take as an argument.
In that case, throwing the Error can be done conditionally, which is
something that couldn't be replicated at compile time.
Stuart.
[1] yes, I vote for Error, FWIW, but I could live with anything that's a
distinct class - ie not 'new RuntimeException("NYI")' - wherever it's
placed in the Exception hierarchy.
--
Stuart Ballard, Senior Web Developer
FASTNET - Web Solutions
(215) 283-2300, ext. 126
www.fast.net
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Andrew Haley wrote: > Out of interest (and please forgive me if this has already been > discussed at length) why have dummy methods at all? Wouldn't it be > better to have a compile time failure for unimplemented methods? I think so, but sometimes (e.g. when implementing interfaces or extending abstract classes), you're required to provide the methods, but I agree that not having the unimplemented method is the cleanest solution. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Andrew Haley wrote: > Andy Walter writes: > > a surprising lot of emails have been sent about that > matter. It seems that we > > all agree on that throwing *something* would be better > than what we have > > currently. The attached class is a summary of what as far > I understood from > > the emails most people here wanted. > > I'm utterly baffled why you think that the attached class is > appropriate. There was a disagreement as to whether a subclass of > Error or of Exception is required. Last I heard, the promoters of > Error threw in the towel. Howver, your class says Exception in the > comments but Error in the code. I'm certainly not throwing in the towel ;-) I think it should be an error, but I can live with NYIException being an Exception, what I cannot accept is (ab)using UnsupportedOperationException. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Jeroen Frijters writes: > Andrew Haley wrote: > > Andy Walter writes: > > > a surprising lot of emails have been sent about that > > matter. It seems that we > > > all agree on that throwing *something* would be better > > than what we have > > > currently. The attached class is a summary of what as far > > I understood from > > > the emails most people here wanted. > > > > I'm utterly baffled why you think that the attached class is > > appropriate. There was a disagreement as to whether a subclass of > > Error or of Exception is required. Last I heard, the promoters of > > Error threw in the towel. Howver, your class says Exception in the > > comments but Error in the code. > > I'm certainly not throwing in the towel ;-) I think it should be an > error, but I can live with NYIException being an Exception, what I > cannot accept is (ab)using UnsupportedOperationException. Out of interest (and please forgive me if this has already been discussed at length) why have dummy methods at all? Wouldn't it be better to have a compile time failure for unimplemented methods? Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
NYIException
Hi all,
a surprising lot of emails have been sent about that matter. It seems that we
all agree on that throwing *something* would be better than what we have
currently. The attached class is a summary of what as far I understood from
the emails most people here wanted.
Personally, I had preferred some standardised information about the JDK
version that demands for the missing feature, but I didn't get the impression
that many of you support that idea.
Is there anybody who can't live with the attached proposal?
Cheers,
Andy.
--
aicas GmbH
Haid-und-Neu-Straße 18 * 76131 Karlsruhe
http://www.aicas.com
Tel: +49-721-663 968-24; Fax: +49-721-663 968-94
/* NotYetImplementedError.java -- Error signaling not yet implemented methods
Copyright (C) 2003 Free Software Foundation
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. */
package gnu.classpath;
/**
* This Exception is used to signal that a particular method has not
* been implemented yet. The use of a specific exception throught the
* complete source code will help to localize and implement missing
* functionality.
* Usage:
*
* public notYetImplementeMethod()
*{
*throw new gnu.classpath.NotYetImplementedError();
*}
*
*
*/
public class NotYetImplementedError extends Error
{
private static final String NYI =
"This method has not yet been implemented in GNU Classpath.\n\n"
+ " The GNU Classpath project would appreciate receiving"
+ " an implementation for it.\n"
+ " If you intend to contribute, please take a look at"
+ " http://www.gnu.org/software/classpath/docs/hacking.html and"
+ " get in touch with other developers on [EMAIL PROTECTED]";
/**
* Create new NotYetImplementedError.
*/
public NotYetImplementedError()
{
super(NYI);
}
/**
* Create new NotYetImplementedError with detailed message.
* @param message more detailed description.
*/
public NotYetImplementedError(String message)
{
super(message + "\n" + NYI);
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
NYIException
Andy Walter writes: > Hi all, > > a surprising lot of emails have been sent about that matter. It seems that we > all agree on that throwing *something* would be better than what we have > currently. The attached class is a summary of what as far I understood from > the emails most people here wanted. I'm utterly baffled why you think that the attached class is appropriate. There was a disagreement as to whether a subclass of Error or of Exception is required. Last I heard, the promoters of Error threw in the towel. Howver, your class says Exception in the comments but Error in the code. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi, I believe the functionality of @unimplemented would be adequately replaced by @since and throw new UnsupportedOperationException. To find out what methods of, e.g., JDK1.2 are unsupported, you can simply search for methods that have @since 1.2 and throw UnsupportedOperationException from their body. I don't see how @unimplemented or NotYetImplementedException would give extra information. The reason for not implementing the method could be explained in normal Javadoc comments, and this avoids generated documentation missing out this information, as would happen if one ran Sun Javadoc over a method with an @unimplemented tag, as far as I know. Regards, Ricky. On Fri, Sep 26, 2003 at 02:38:30PM +0200, Sascha Brawer wrote: > What would you say about defining a special Javadoc tag, such as the > following? > > /** > * @unimplemented 1.4 Here comes some explanation. > */ > [class|method|field] > > It would not be too difficult to write a special doclet for the purpose > of generating a document that summarizes the implementation status. Plus, > it would be possible to document what exactly is not implemented, the > reason, etc. The explanation text would also go into the generated > documentation files. > > -- Sascha > > Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ > > > > > ___ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
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: NYIException
David Holmes wrote:
- UnsupportedOperationException
+ semantically close in meaning
+ allows simple use of try/catch in portable programs
- not uniquely defining ie grepping for it will give false results
The proposal from March takes care of this:
throw new UnsupportedOperationException("not implemented[ - optional
reason]");
This makes grep easy.
+ No new classes needed.
+ No dependency on non-standard classes. I.e. somebody can contribute
an incomplete implementation of a class that without having to depend
on ClassPath.
- NYIException
+ semantically exact in meaning
True. However to what extent is this useful?
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
___
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
Re: NYIException
David Holmes wrote: Anyway it seems the two exception approaches are functionally equivalent and it's really a matter of style/preference now: - UnsupportedOperationException + semantically close in meaning + allows simple use of try/catch in portable programs Only if portable means java 1.2 and above. There was no such class before java 1.2, it arrived with the collections framework API. ;) - not uniquely defining ie grepping for it will give false results cheers, dalibor topic ___ 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
RE: NYIException
> Kind of ;) I think it's been around since java 1.0, so it > would predate > the reflection APIs that ararived with java 1.1, AFAIK. ;) It does predate the java.lang.reflect API's, but it is still (structural) reflection. Anyway it seems the two exception approaches are functionally equivalent and it's really a matter of style/preference now: - UnsupportedOperationException + semantically close in meaning + allows simple use of try/catch in portable programs - not uniquely defining ie grepping for it will give false results - NYIException + semantically exact in meaning + uniquely defining + can be accommodated for by portable programs - requires a little more effort in catch blocks to identify Toss a coin. Cheers, David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
David Holmes wrote:
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.
e.getClass().getName() *is* reflection in my book :-)
Kind of ;) I think it's been around since java 1.0, so it would predate
the reflection APIs that ararived with java 1.1, AFAIK. ;)
cheers,
dalibor topic
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
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).
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
RE: NYIException
> 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.
e.getClass().getName() *is* reflection in my book :-)
David Holmes
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
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
Re: NYIException
David Holmes wrote: Seems to me that this is a RuntimeException then. Only an application that is being written for Classpath will be able to take alternative action if core functionality is missing. Any other application will just have to throw up its hands. On the other hand, if the exception is UnsupportedOperationException then it is possible for a portable application to try an alternative approach - which may work. If the exception is a new class, then that is not possible. If it doesn't catch it, then nothing is lost. It should *NOT* be a subclass of an existing exception type that has well defined semantics and is likely to be caught in general applications - like UnsupportedOperationException. I agree with Jeroen that not being implemented when it should be, is quite distinct from not supporting an optional operation. 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. But more important is throwing *some* exception. We *must* fix the current situation where unimplemented methods silently do nothing or return null. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Stephen Crawley wrote: > I agree. We should not be subclassing Error, or one of its > descendents. > Error is reserved for things that an application has no hope in hell > of recovering from. Seems to me that this is a RuntimeException then. Only an application that is being written for Classpath will be able to take alternative action if core functionality is missing. Any other application will just have to throw up its hands. It should *NOT* be a subclass of an existing exception type that has well defined semantics and is likely to be caught in general applications - like UnsupportedOperationException. I agree with Jeroen that not being implemented when it should be, is quite distinct from not supporting an optional operation. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Stephen, Stephen Crawley wrote: Jeroen Frijters wrote: Andrew Haley wrote: My only argument was against subclassing Error, because the Java specification strongly implies that the only reasonable thing to do when receiving an Error is issue a disgnostic and die. I agree. We should not be subclassing Error, or one of its descendents. Error is reserved for things that an application has no hope in hell of recovering from. Sub-classing UnsupportedOperationException would be compatible with existing JDK semantics and Java style. However, it does tend to lockin application code to a platform based on Classpath ... which is a bad idea. Even your idea of using a static to throw the NYIException doesn't prevent this because the lockin happens when the application refers to (e.g. catches) NYIException. There is no lockin, as NYIException (in)directly extends RuntimeException. I can catch RuntimeExceptions all day long without being locked into a particular implementation's subclass. Application code that willfully uses internal classes of a runtime, be it sun.*, com.sun.*, com.ibm.*, or gnu.* is not portable anyway, so there is no harm done. In the case of unimplemented Classpath methods, this seems rather extreme. Why? I don't see how you can reasonably continue given that an arbitrary functionality that the application depends on is missing. Depending on what platform functionality is missing, it may be possible for an application to be coded to "do it another way". For example, a product we're developing at work is designed to use the XML Schema functionality. But if the Java platform does not support XML Schemas, it can fall back to using the simple XML. Works equally well with exception handlers: Oops, we got a runtime exception trying method a, let's try method b. No problem there. ;) Alternatively, an application's error reporting may need to catch "not yet implemented" exceptions to generate a specific diagnostic for the end user. For example, you may want to advise the user to upgrade their Java platform ... in accordance with application release notes that they probably didn't read properly in the first place :-) You can't do this right now with Classpath anyway, as there is no way to know if a method is not implemented, or just does nothing on purpose. No harm done here either. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Jeroen Frijters wrote: > Andrew Haley wrote: > > My only argument was against subclassing Error, because the Java > > specification strongly implies that the only reasonable thing to do > > when receiving an Error is issue a disgnostic and die. I agree. We should not be subclassing Error, or one of its descendents. Error is reserved for things that an application has no hope in hell of recovering from. Sub-classing UnsupportedOperationException would be compatible with existing JDK semantics and Java style. However, it does tend to lockin application code to a platform based on Classpath ... which is a bad idea. Even your idea of using a static to throw the NYIException doesn't prevent this because the lockin happens when the application refers to (e.g. catches) NYIException. > > In the case of unimplemented Classpath methods, this seems rather > > extreme. > Why? I don't see how you can reasonably continue given that an arbitrary > functionality that the application depends on is missing. Depending on what platform functionality is missing, it may be possible for an application to be coded to "do it another way". For example, a product we're developing at work is designed to use the XML Schema functionality. But if the Java platform does not support XML Schemas, it can fall back to using the simple XML. Alternatively, an application's error reporting may need to catch "not yet implemented" exceptions to generate a specific diagnostic for the end user. For example, you may want to advise the user to upgrade their Java platform ... in accordance with application release notes that they probably didn't read properly in the first place :-) However, an application developer should probably avoid doing this kind of thing with a non-standard (Classpath specific) exception class unless he/she is prepared to be locked into a Classpath-based Java platform. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Andrew Haley wrote: > > Why? I don't see how you can reasonably continue given that an > > arbitrary functionality that the application depends on is missing. > > Think about the "programming by contract" metaphor: the application is > a customer, and the implementation is a contractor. It is not up to a > contractor to decide whether failure to do a particular job should > cause the whole project to be cancelled. That decision rests soley > with the customer. That is because the contractor does not know how > important a particular job is. > > An application can decide to carry on, and is perfectly entitled to do > so. IMHO, this comparison is misleading because applications cannot "decide" anything. The programmer is the one doing the deciding. If an application doesn't explicitly target Classpath, it is unreasonable to expect the programmer to deal with this failure. If the programmer is targeting Classpath, it is easy enough to handle the NYI exception. Maybe we should have a static method instead of directly throwing an exception, that way it is easy to change the behavior. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Jeroen Frijters writes: > [I'm resending this, apologies if you get it twice] > > Andrew Haley wrote: > > My only argument was against subclassing Error, because the Java > > specification strongly implies that the only reasonable thing to > > do when receiving an Error is issue a disgnostic and die. > > I apologize for the confusion. > > > In the case of > > unimplemented Classpath methods, this seems rather extreme. > > Why? I don't see how you can reasonably continue given that an > arbitrary functionality that the application depends on is missing. Think about the "programming by contract" metaphor: the application is a customer, and the implementation is a contractor. It is not up to a contractor to decide whether failure to do a particular job should cause the whole project to be cancelled. That decision rests soley with the customer. That is because the contractor does not know how important a particular job is. An application can decide to carry on, and is perfectly entitled to do so. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
[I'm resending this, apologies if you get it twice] Andrew Haley wrote: > My only argument was against subclassing Error, because the Java > specification strongly implies that the only reasonable thing to do > when receiving an Error is issue a disgnostic and die. I apologize for the confusion. > In the case of > unimplemented Classpath methods, this seems rather extreme. Why? I don't see how you can reasonably continue given that an arbitrary functionality that the application depends on is missing. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Jeroen Frijters writes: > Michael Koch wrote: > > Am Samstag, 27. September 2003 10:43 schrieb Jeroen Frijters: > > > Per Bothner wrote: > > > > >>We discussed this in March, and there was agreement that we > > > > >>should use use UnsupportedOperationException. > > > > >> > > > > >>See http://gcc.gnu.org/ml/java/2003-03/msg00016.html > > > > > > > > > > Its never too late to rethink something. > > > > > > > > But unless one is aware of previous discussion (and even if one > > > > is), much time may be wasted. So far I haven't seen any reason > > > > why we need to re-consider the previous consensus. > > > > > > I just re-read the previous discussion and there Andrew Haley wrote: > > > > UnsupportedOperationException is a good choice. Any subclass of > > > > Error is not, because according to the spec Error "indicates > > > > serious problems that a reasonable application should not try to > > > > catch." > > > > > > IMNSHO, this is *exactly* why we must define a new exception > > > derived from Error. An unimplemented method *is* a serious problem > > > that a reasonable application should not try to catch. > > > > > > So, I think it is an extremely bad idea to use > > > UnsupportedOperationException (or a subclass of it). > > > > Have you misread Andrew's comment ? I read it exaclty the other way > > around then you. > > I didn't misread it, I just strongly disagree with it. If Andrew's > argument was the reason UnsupportedOperationException was chosen, I > think we need to reconsider. > > Surely there is defensively written code out there that handles > UnsupportedOperationException (for example, when dealing with > collections), this will consume our UnsupportedOperationException > (which really means something quite different) and make diagnosing > the problem extremely hard. When an application depends on missing > functionality I want to see the exception and reduce the chance > that the app accidentally eats the exception. My only argument was against subclassing Error, because the Java specification strongly implies that the only reasonable thing to do when receiving an Error is issue a disgnostic and die. In the case of unimplemented Classpath methods, this seems rather extreme. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Per,
Per Bothner wrote:
We discussed this in March, and there was agreement that we
should use use UnsupportedOperationException.
See http://gcc.gnu.org/ml/java/2003-03/msg00016.html
I agree there was an agreement that something should be done, and the
practice of returning null/nothing was 'evil', but I didn't parse the
discussion as specifically nailing down UnsupportedOperationException or
UnsupportedOperationException(String reason) as the particular
implementation to pick.
When your proposal came up again on the Classpath mailing list after the
LinuxTag meeting, it was ammended by me and Andy Walter to the
NYIException with a verbose 'please contribute' message. Again, no
decision was made in favor or against it. See
http://mail.gnu.org/archive/html/classpath/2003-07/msg00053.html
So it's back at the table, in my opinion, and I hope this time around we
can agree on a concrete implementation ;) I'd like to point out my
arguments in favor of a specific NotYetImplementedException:
a) it would be easy to write a tool that walks over classpath's rt.jar,
loads the classes using Class.forName, uses reflection to check which
methods are not implemented yet, and produces simple todo lists.
b) It makes it clear that a method is not implemented, whereas an
UnsupportedOperationException already has a different meaning: it means
that a collection class doesn't support an optional operation. In my
opinion, there is nothing optional about non-implementing a method. ;)
So having NotYetImplementedException extend
UnsupportedOperationException would be semantically confusing, as it
mixes what's allowed by the API with what we know is wrong, but didn't
get around to fix yet. The behaviour for code that catches
UnsupportedOperationException would be weird, too, as the code would
silently change its behaviou as Classpath improves, and the
unimplemented method is implemented. That's not something I'd want when
I program against an otherwise stable API.
c) It comes with a beautiful motivational message. It tried to motivate
the people who want to run their code on top of classpath, and it
doesn't work, to try to fix it.
d) It can be easily extended to cover additional information if
necessary, like API version:
{
public static API extends Object {
private API(){};
}
public static final API 1_0 = new API();
public static final API 1_1 = new API();
...
private static final String help = "Fix GNU Classpath now!";
private API api;
private String reason;
public NotYetImplementedException(String reason, API api) {
this.reason = reason;
this.api = api;
}
public NotYetImplementedException(String reason) {
this.reason = reason;
}
}
cheers,
dalibor topic
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 27. September 2003 01:03 schrieb Per Bothner: > Michael Koch wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Am Freitag, 26. September 2003 19:29 schrieb Per Bothner: > >>We discussed this in March, and there was agreement that we > >>should use use UnsupportedOperationException. > >> > >>See http://gcc.gnu.org/ml/java/2003-03/msg00016.html > > > > Its never too late to rethink something. > > But unless one is aware of previous discussion (and even if one > is), much time may be wasted. So far I haven't seen any reason why > we need to re-consider the previous consensus. well, there are some reasons against the old decission. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dVxTWSOgCCdjSDsRAiNSAKCD5/BSZasIyn72hZhFa77dOAOCuQCfT/Ty Ydgw1wR57yX0nlApCCnaJjM= =nxio -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 27. September 2003 11:11 schrieb Jeroen Frijters: > > Have you misread Andrew's comment ? I read it exaclty the other > > way around then you. > > I didn't misread it, I just strongly disagree with it. If Andrew's > argument was the reason UnsupportedOperationException was chosen, I > think we need to reconsider. Yes. > Surely there is defensively written code out there that handles > UnsupportedOperationException (for example, when dealing with > collections), this will consume our UnsupportedOperationException > (which really means something quite different) and make diagnosing > the problem extremely hard. When an application depends on missing > functionality I want to see the exception and reduce the chance > that the app accidentally eats the exception. Well, thats my concern too. Summarized inheriting from either UnsupportedOperationException or Error is bad. Just inheriting from Exception might not be. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dVbwWSOgCCdjSDsRAg9eAJ4zJpofhG7tQsSiT4iRbWFX6vFbHACfX/Gz YccHJ9M6jHR/JQ6AlnfxUso= =sdgC -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Michael Koch wrote: > Am Samstag, 27. September 2003 10:43 schrieb Jeroen Frijters: > > Per Bothner wrote: > > > >>We discussed this in March, and there was agreement that we > > > >>should use use UnsupportedOperationException. > > > >> > > > >>See http://gcc.gnu.org/ml/java/2003-03/msg00016.html > > > > > > > > Its never too late to rethink something. > > > > > > But unless one is aware of previous discussion (and even if one > > > is), much time may be wasted. So far I haven't seen any reason > > > why we need to re-consider the previous consensus. > > > > I just re-read the previous discussion and there Andrew Haley wrote: > > > UnsupportedOperationException is a good choice. Any subclass of > > > Error is not, because according to the spec Error "indicates > > > serious problems that a reasonable application should not try to > > > catch." > > > > IMNSHO, this is *exactly* why we must define a new exception > > derived from Error. An unimplemented method *is* a serious problem > > that a reasonable application should not try to catch. > > > > So, I think it is an extremely bad idea to use > > UnsupportedOperationException (or a subclass of it). > > Have you misread Andrew's comment ? I read it exaclty the other way > around then you. I didn't misread it, I just strongly disagree with it. If Andrew's argument was the reason UnsupportedOperationException was chosen, I think we need to reconsider. Surely there is defensively written code out there that handles UnsupportedOperationException (for example, when dealing with collections), this will consume our UnsupportedOperationException (which really means something quite different) and make diagnosing the problem extremely hard. When an application depends on missing functionality I want to see the exception and reduce the chance that the app accidentally eats the exception. Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 27. September 2003 10:43 schrieb Jeroen Frijters: > Per Bothner wrote: > > >>We discussed this in March, and there was agreement that we > > >>should use use UnsupportedOperationException. > > >> > > >>See http://gcc.gnu.org/ml/java/2003-03/msg00016.html > > > > > > Its never too late to rethink something. > > > > But unless one is aware of previous discussion (and even if one > > is), much time may be wasted. So far I haven't seen any reason > > why we need to re-consider the previous consensus. > > I just re-read the previous discussion and there Andrew Haley wrote: > > UnsupportedOperationException is a good choice. Any subclass of > > Error is not, because according to the spec Error "indicates > > serious problems that a reasonable application should not try to > > catch." > > IMNSHO, this is *exactly* why we must define a new exception > derived from Error. An unimplemented method *is* a serious problem > that a reasonable application should not try to catch. > > So, I think it is an extremely bad idea to use > UnsupportedOperationException (or a subclass of it). Have you misread Andrew's comment ? I read it exaclty the other way around then you. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dVD3WSOgCCdjSDsRArN/AJ9PrMom242bOP0UN8OjtQJPDzbimwCeNQoS siqmZamyzq0EJYV/3UwQ3N4= =uxdc -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
Per Bothner wrote: > >>We discussed this in March, and there was agreement that we > >>should use use UnsupportedOperationException. > >> > >>See http://gcc.gnu.org/ml/java/2003-03/msg00016.html > > > > > > Its never too late to rethink something. > > But unless one is aware of previous discussion (and even if one is), > much time may be wasted. So far I haven't seen any reason why we > need to re-consider the previous consensus. I just re-read the previous discussion and there Andrew Haley wrote: > UnsupportedOperationException is a good choice. Any subclass of > Error is not, because according to the spec Error "indicates > serious problems that a reasonable application should not try to > catch." IMNSHO, this is *exactly* why we must define a new exception derived from Error. An unimplemented method *is* a serious problem that a reasonable application should not try to catch. So, I think it is an extremely bad idea to use UnsupportedOperationException (or a subclass of it). Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Michael Koch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 26. September 2003 19:29 schrieb Per Bothner: We discussed this in March, and there was agreement that we should use use UnsupportedOperationException. See http://gcc.gnu.org/ml/java/2003-03/msg00016.html Its never too late to rethink something. But unless one is aware of previous discussion (and even if one is), much time may be wasted. So far I haven't seen any reason why we need to re-consider the previous consensus. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 26. September 2003 19:29 schrieb Per Bothner: > We discussed this in March, and there was agreement that we > should use use UnsupportedOperationException. > > See http://gcc.gnu.org/ml/java/2003-03/msg00016.html Its never too late to rethink something. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dJpeWSOgCCdjSDsRAisAAJ0T/kIYtwVwRPMPWTovHxw6o5LrggCeOaqE M42w9sa6cjnT3onk+2aNBrQ= =sB5D -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
We discussed this in March, and there was agreement that we should use use UnsupportedOperationException. See http://gcc.gnu.org/ml/java/2003-03/msg00016.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: NYIException
There is a semantic difference between something not supported, and something not implemented. There are iterators where I purposely throw an UnsupportedOperationException() for remove() because it would be impossible to do. That is very different from a NotYetImplementedException which tells the programmer that they should be able to do this, but not quite yet. Perhaps the default message for the NotYetImplementedException should be "patches welcome." --Avery -Original Message- From: Sascha Brawer [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 11:34 AM To: GNU Classpath Subject: Re: NYIException Hi Andy, >> [NotYetImplementedException] > [JavaDoc tag] > >Do you mean additionally to the exception or instead? With a JavaDoc tag (or some other convention for comments), there would be no need to distinguish between NotYetImplementedException_1_3, NotYetImplementedException_1_4, etc. I agree that some exception should be thrown. But it might suffice to just throw java.lang.UnsupportedOperationException. Not that I would oppose a special NotYetImplementedException. Living in a neutral country, I don't have an explicit opinion about such matters. :-) -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Michael, On Friday 26 September 2003 17:56, Michael Koch wrote: > I'm for UnsupportedOperationException too because it exists already > and dont have to invent something new. > > A reason against using it is that some methods return UOE by design in > some situations. That means that i may not be clear in any case if > the method throwns an exception because its unimplementd or because > of other reasons. How about NotYetImplementedException extends UnsupportedOperationException then to distinguish between the above cases? IMHO, it would be quite useful for the project being able to say "we are able to run any JDK 1.2 programme". A script that has to know about which method might throw UnsupportedOperationException and which shouldn't could never be really reliable. Cheers, Andy. -- aicas GmbH Haid-und-Neu-Straße 18 * 76131 Karlsruhe http://www.aicas.com Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 26. September 2003 17:33 schrieb Sascha Brawer: > Hi Andy, > > >> [NotYetImplementedException] > > > > [JavaDoc tag] > > > >Do you mean additionally to the exception or instead? > > With a JavaDoc tag (or some other convention for comments), there > would be no need to distinguish between > NotYetImplementedException_1_3, NotYetImplementedException_1_4, > etc. > > I agree that some exception should be thrown. But it might suffice > to just throw java.lang.UnsupportedOperationException. Not that I > would oppose a special NotYetImplementedException. Living in a > neutral country, I don't have an explicit opinion about such > matters. :-) I'm for UnsupportedOperationException too because it exists already and dont have to invent something new. A reason against using it is that some methods return UOE by design in some situations. That means that i may not be clear in any case if the method throwns an exception because its unimplementd or because of other reasons. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dGGqWSOgCCdjSDsRAvuNAKCMksQtOJr8Ga6eNjFeJiVYotBPygCfZgey l0YjZDXcnpIWl1fgrdSJlwY= =WQ/V -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Andy, >> [NotYetImplementedException] > [JavaDoc tag] > >Do you mean additionally to the exception or instead? With a JavaDoc tag (or some other convention for comments), there would be no need to distinguish between NotYetImplementedException_1_3, NotYetImplementedException_1_4, etc. I agree that some exception should be thrown. But it might suffice to just throw java.lang.UnsupportedOperationException. Not that I would oppose a special NotYetImplementedException. Living in a neutral country, I don't have an explicit opinion about such matters. :-) -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Sascha, On Friday 26 September 2003 14:38, Sascha Brawer wrote: > >> > [NotYetImplementedException] > > What would you say about defining a special Javadoc tag, such as the > following? > > /** > * @unimplemented 1.4 Here comes some explanation. > */ > [class|method|field] Do you mean additionally to the exception or instead? I like the idea of using something like that additionally to the exception, but to me, it doesn't replace an exception because somebody whose programme doesn't work because of something missing in Classpath for sure has less trouble finding it if the method raises an exception. However, an unimplemented tag for giving more details about the missing code is a good idea. Cheers, Andy. -- aicas GmbH Haid-und-Neu-Straße 18 * 76131 Karlsruhe http://www.aicas.com Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Andy Walter <[EMAIL PROTECTED]> wrote on Fri, 26 Sep 2003 12:50:20 +0200: >> > [NotYetImplementedException] >> >> Not sure we even need the extra exception type, just finding all the >> spots to throw the UnsupportedOperationException and doing that would >> probably be more than enough. > >The motivation is that, while we currently cannot even tell what methods are >missing, with such a NotYetImplementedException and subclasses >NotYetImplementedException_1_2, NotYetImplementedException_1_3, and >NotYetImplementedException_1_4 we would be able to write a script similar to >JAPI tools that gives an overview about how complete Classpath is according >to a certain JDK specification. We'd like to go through the classes and >annotate what features are not yet implemented (completely). When we do it >this way, it is no additional effort to annotate the corresponding >specification version, which will be some really valueable information in the >future. What would you say about defining a special Javadoc tag, such as the following? /** * @unimplemented 1.4 Here comes some explanation. */ [class|method|field] It would not be too difficult to write a special doclet for the purpose of generating a document that summarizes the implementation status. Plus, it would be possible to document what exactly is not implemented, the reason, etc. The explanation text would also go into the generated documentation files. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Brian, On Friday 26 September 2003 00:43, Brian Jones wrote: > > [NotYetImplementedException] > > Not sure we even need the extra exception type, just finding all the > spots to throw the UnsupportedOperationException and doing that would > probably be more than enough. The motivation is that, while we currently cannot even tell what methods are missing, with such a NotYetImplementedException and subclasses NotYetImplementedException_1_2, NotYetImplementedException_1_3, and NotYetImplementedException_1_4 we would be able to write a script similar to JAPI tools that gives an overview about how complete Classpath is according to a certain JDK specification. We'd like to go through the classes and annotate what features are not yet implemented (completely). When we do it this way, it is no additional effort to annotate the corresponding specification version, which will be some really valueable information in the future. Cheers, Andy. -- aicas GmbH Haid-und-Neu-Straße 18 * 76131 Karlsruhe http://www.aicas.com Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Ingo Prötel <[EMAIL PROTECTED]> writes: > Hi Sascha, > > > Sascha Brawer wrote: > > Ingo Prötel <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 16:56:23 +0200: > > > >> I would like to again propose a standard NYIException to be used in > >> Classpath. > >> > >>[...] > >> > >>package gnu.org.classpath; > > Are you sure about this package name? > > This should be > package gnu.classpath; > > > >> public class NYIException extends UnsupportedOperationException > > I'd favor "NotYetImplementedException". Class names tend to be very > > verbose in Java, and IMHO it would make sense to follow that style. Not sure we even need the extra exception type, just finding all the spots to throw the UnsupportedOperationException and doing that would probably be more than enough. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Ingo Prötel wrote: We can certainly do this. I also appreciate if an exception name already describes the problem. But I also must caution against using too long names. Especially for classes with inner classes. Such Classes result in very long class-filenames. Some Systems have hard limits on these names. Something like: Collections$UnmodifiableMap$UnmodifiableEntrySet$1$1.class will not work on a QNX system with a limit of 48 chars in a filename. On such system, you should simply put the classes in a .jar file. Th think that we should not limit the readability an intuitiveness of the source code for such system-specific problem. 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: NYIException
On Thu, 25 Sep 2003 15:43:10 +0200 Sascha Brawer <[EMAIL PROTECTED]> wrote: > I'd favor "NotYetImplementedException". Class names tend to be very > verbose in Java, and IMHO it would make sense to follow that style. ... even if NY is exceptionnel! ;) -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Hi Sascha, Sascha Brawer wrote: Ingo Prötel <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 16:56:23 +0200: I would like to again propose a standard NYIException to be used in Classpath. [...] package gnu.org.classpath; Are you sure about this package name? This should be package gnu.classpath; public class NYIException extends UnsupportedOperationException I'd favor "NotYetImplementedException". Class names tend to be very verbose in Java, and IMHO it would make sense to follow that style. We can certainly do this. I also appreciate if an exception name already describes the problem. But I also must caution against using too long names. Especially for classes with inner classes. Such Classes result in very long class-filenames. Some Systems have hard limits on these names. Something like: Collections$UnmodifiableMap$UnmodifiableEntrySet$1$1.class will not work on a QNX system with a limit of 48 chars in a filename. But since this will likely not be a problem on an exception I will take the long name. --ingo -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Donnerstag, 25. September 2003 15:43 schrieb Sascha Brawer: > Ingo Prötel <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 16:56:23 +0200: > >I would like to again propose a standard NYIException to be used > > in Classpath. > > > >[...] > > > >package gnu.org.classpath; > > Are you sure about this package name? IMO gnu.classpath would be the correct package name. > >public class NYIException extends UnsupportedOperationException > > I'd favor "NotYetImplementedException". Class names tend to be very > verbose in Java, and IMHO it would make sense to follow that style. I second this. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cvnRWSOgCCdjSDsRAtVgAJ4kfadDQAXX4C13tzR3al0naBWlQQCfaLWy brJeCOkCmcww0e4c6+BDFlY= =EU4d -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: NYIException
Ingo Prötel <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 16:56:23 +0200: >I would like to again propose a standard NYIException to be used in >Classpath. > >[...] > >package gnu.org.classpath; Are you sure about this package name? >public class NYIException extends UnsupportedOperationException I'd favor "NotYetImplementedException". Class names tend to be very verbose in Java, and IMHO it would make sense to follow that style. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
NYIException
Hi,
I would like to again propose a standard NYIException to be used in
Classpath.
I have taken earlier postings this list and copied them into a
java-file. I have attached the result.
I would like your comments. If nobody complains I will put it in.
One open issue with this approach is that we are not able to
differentiate between features of different Java releases.
To solve this we could have subclasses of this exception:
NYI14Exception -- new feature in release 1.4
NYI13Exception -- new feature in release 1.3
...
This would make a grep really easy.
--ingo
/* NYIException.java -- Exception signaling not yet implemented methods
Copyright (C) 2003 Free Software Foundation
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. */
package gnu.org.classpath;
/**
* This Exception is used to signal that a particular method has not
* been implemented yet. The use of a specific exception throught the
* complete source code will help to localize and implement missing
* functionality.
* Usage:
*
* public notYetImplementeMethod()
*{
*throw new gnu.classpath.NYIException();
*}
*
*
*/
public class NYIException extends UnsupportedOperationException
{
private static final String NYI =
"This method has not yet been implemented in GNU Classpath.\n\n"
+ " The GNU Classpath project would appreciate receiving"
+ " an implementation for it.\n"
+ " If you intend to contribute, please take a look at"
+ " http://www.gnu.org/software/classpath/docs/hacking.html and"
+ " get in touch with other developers on [EMAIL PROTECTED]";
/**
* Create new NYIException.
*/
public NYIException()
{
super(NYI);
}
/**
* Create new NYIException with detailed message.
* @param message more detailed description.
*/
public NYIException(String message)
{
super(message + "\n" + NYI);
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
