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: RFC on patch [bug #4968]
Hi, On Sun, 2003-09-28 at 21:41, Guilhem Lavaux wrote: > I know that I don't write that much ChangeLog ... but could someone can > have a look at > http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4968&group_id=85 and > tell me if it sees something against comitting it in the repository. I > would like to speed up the process of merging between Kaffe's and > Classpath's CVS. Sorry Guilhem. I looked at this, but since I didn't have enough time to really evaluate it (java.text is not my field of expertise I am afraid) I didn't commit it right away. There doesn't seem to be anything wrong with it from a quick look though. So if someone does have time to read over it and create a real ChangeLog entry, please check this in. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Workshop Oct. 14
Hi Sascha, thank you for taking the burden of organizing this! Here are my (small) propositions. I would like to hear the people / projects taking part to the BoF present the goals of their projects and their roadmap, to know what is going on and in which direction classpath will (or will have to) evolve, and identify possible synergies. I think that your idea of making an extended tasklist (including required knowledge and estimated work) is great; the BoF should continue this, by identifying other possible tasks. Maybe it is possible to find more developers by launching this as "adopt a piece of classpath" or with some other funny/fancy slogans The VM integration is also an important point. We could work on improving the VM Integration Guide by explaining the rationale of this design, in particular when are VM classes used instead of native methods and vice versa (and thereafter checking whether the code follows this rationale). And maybe (but only as last topic) you could schedule the discussion about the NotYedImplementedException, as I guess the list may not have reached an agreement on this before the LinuxKongress. -Patrik - Original Message - From: "Sascha Brawer" <[EMAIL PROTECTED]> To: "GNU Classpath" <[EMAIL PROTECTED]> Sent: Friday, September 26, 2003 5:23 PM Subject: Workshop Oct. 14 > Hi all, > > as announced, there will be workshop for GNU Classpath developers on > October 14 in Saarbrücken/Germany. > > Does anyone wish to discuss a specific topic, in addition to graphics? > I'd like to prepare an agenda for the afternoon, so we can make most of > the time. > > Best regards, > > -- 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: > > 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
RFC on patch [bug #4968]
Hi, I know that I don't write that much ChangeLog ... but could someone can have a look at http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4968&group_id=85 and tell me if it sees something against comitting it in the repository. I would like to speed up the process of merging between Kaffe's and Classpath's CVS. Regards, Guilhem. ___ 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: FYI: Patch: java.text.SimpleDateFormat
Bryce McKinlay wrote: On Sunday, Sep 28, 2003, at 11:04 Pacific/Auckland, Mark Wielaard wrote: Hi, On Sat, 2003-09-27 at 22:21, Bryce McKinlay wrote: Can you give me a pointer to the failing mauve test? Without the patch the following four mauve tests fail: FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: CDT (number 1) FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: EDT (number 1) FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: EST (number 1) FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: PDT (number 1) Thanks Mark. The real problem here is that setTimeZone() was being called on the underlying calendar. This is not necessary since the ZONE_OFFSET field has the same effect, without overwriting the timezone which the user set and "sticking" across a calendar.clear() call. The cloning approach only worked by chance, since it reset the calendar's timezone to GMT which just happened to be what the test case expected. I'm checking in this patch to libgcj & classpath. Ok, that's seem right. I was considering calendar like if it was given by an external user. Apparently you got the point. Regards, Guilhem. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
