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: 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
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: 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
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
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
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
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
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
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
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. 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 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
[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: [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
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 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
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
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
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
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
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
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
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
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: 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
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: 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
-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
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 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
-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
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
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-Strae 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
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
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
-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 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
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
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
-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
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
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
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
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
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
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
Ingo Prtel [EMAIL PROTECTED] writes: Hi Sascha, Sascha Brawer wrote: Ingo Prtel [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
