Re: Patch: merge File.toURI() from Classpath
Hi, On Wed, 2004-07-07 at 05:21, Stephen Crawley wrote: For the record, grep tells me that Sun's JDK 1.4.2 class libraries throws InternalError in 145 places. Notwithstanding the wording of the InternalError javadoc, Sun uses it extensively for library errors. In a couple of cases, the comments that indicated that the developer thought that InternalError was the wrong exception ... but used it anyway. On the other hand, grep tells me that JDK 1.4.2 throws RuntimeException in 157 places. Quick note. As pointed out in the GNU Classpath Hacker Guide http://www.gnu.org/software/classpath/docs/hacking.html#SEC2 Never under any circumstances refer to proprietary code while working on GNU Classpath. GNU Classpath can be developed while just relying on free software tools. Please make this as easy as possible for everybody and just use only free software whenever you can. Yes, I know that running grep over a bunch of source files isn't the same as studying some proprietary implementation while working on a free implementation like GNU Classpath. But we like to make it as clear and easy as possible to avoid any confusion about whether or not people hacking on GNU Classpath ever refer to proprietary implementations while working on compatible free implementations. They don't. Keeping it that simple means we don't have to open up a giant can of legal worms. It can easily be kept closed. Thanks, Mark BTW. FWIW. I think Chris has it right. The book by Joshua Bloch makes a very good case. We should just define a ClasspathAssertionFailure that extends RuntimeException and takes a cause (and/or string) as argument. Then at every place we get an unexpected exception that should not happen or some other pre/post condition failure inside the core libraries that was never supposed to happen we throw this. It doesn't even matter that much what another implementation does. We should do it better and more consistent. signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
David Daney wrote: Stephen Crawley writes: I'm also going to submit a bug report about the JDK's widespread abuse of RuntimeException. IMO, they should either throw InternalError (or its replacement) or they should define some appropriate subtypes of RuntimeException and throw those. I agree. IMHO RuntimeException exists for exactly two reasons: 1) To be subclassed. 2) To be caught. It should never be thrown. I don't much like religious wars, but I am stuck using libgcj. So I can't just walk away. I must stand and fight for what I believe in! I don't think this constitutes a religious war, I just think ambiguity leads to problems. So, taking everyone's comments into consideration, how about this as a set of guidelines for Classpath: 1) Treat RuntimeException as if it were abstract (although of course it cannot actually be made abstract because of user code). 2) If Sun throws a documented RuntimeException, throw the most appropriate subclass instead, and if nothing appropriate exists throw something like GNUClasspathException (needs deciding). Track changes by Sun. 3) If Sun throws any other documented Throwable, including InternalError, do the same thing. Users might depend on Sun's specific behaviour. Track changes by Sun. 4) Otherwise, if you need to throw an exception, and it is strictly VM-related, throw an InternalError, since this appears to be the best / intended usage, as it is a subclass of VirtualMachineError. 5) Otherwise, if you need to throw an exception, and it is not strictly VM-related, and the user might have a hope of recovering, throw a subclass of RuntimeException, as per item (2). 6) Otherwise, throw something like UnrecoverableGNUClasspathError (needs deciding). Use this if the application must always die. 7) Document using @throws and use the throws keyword as per Sun's API. If you document too much, this makes it difficult to adjust if Sun ever updates things, because users might rely on Classpath's old behaviour. I think a step-by-step set of instructions like this helps. Are there any major problems, or points that I missed, or is it generally okay? Chris ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Hi, I wrote: I'm going to submit a Sun bug report against the InternalError javadoc. It will suggest that either they change the javadoc wording to match current practice, or they define a new xxxError exception to be thrown for library internal errors. I'm also going to submit a bug report about the JDK's widespread abuse of RuntimeException. IMO, they should either throw InternalError (or its replacement) or they should define some appropriate subtypes of RuntimeException and throw those. I've submitted both reports. But the automatic reply suggests that it will be 3 weeks before a human gets to look at them. Does anyone know of a better / quicker way to get specification clarifications from Sun? -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Bryce McKinlay writes: David Daney wrote: It doesn't seem like a good idea to use an unsuitable exception type just because its API has a slightly more elegant constructor. I do not believe that RuntimeException is unsuitable. It seems a better match than InternalError. Yes, I agree. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Bryce McKinlay wrote: Again, these exceptions should be documented as part of our API documentation. They are exceptions that should _never_ happen. No call from the application should cause them to be thrown, thus they are not part of the API. If they are ever thrown, then there is a bug in classpath. Nevertheless, applications should have the ability to try and continue in the face of classpath bugs if they need fault tolerance. Can't we just use assertions for things that should never happen? cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
[EMAIL PROTECTED] said: Dalibor Topic wrote: Can't we just use assertions for things that should never happen? In this case I think its better not to, because assertions may be disabled in production builds. Ah ... but we could avoid that by explicitly throwing AssertionError. But my preference is to throw InternalError. The current large scale use of InternalError in Sun's implementation makes their javadoc wrong. In the light of this, InternalError is in fact a good fit. Aside: if you want Sun to fix their abuse of RuntimeException, it has Bug/RFE Id: 5071860 on the Sun Bug Parade. In a day or so you should be able to see it / vote for it. -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Bryce McKinlay wrote: Ranjit Mathew wrote: Mohan Embar wrote: Just out of curiosity, why is the result of new InternalError() being explicitly cast to an InternalError? Look closely - it's the return value (a Throwable) from initCause() that is being cast into an InternalError: +// Can't happen. +throw (InternalError) new InternalError(Unconvertible file: + + this).initCause(use); I wonder if we should standardize on using RuntimeException in these cases. A quick grep through the source code shows that we use both InternalError and RuntimeException for these shouldn't/can't happen catch blocks in various cases. I think RuntimeException would be a better choice, since it has a proper cause constructor for re-throwing exceptions. I don't like this idea. RuntimeException is meant to be the base class for Exceptions that can reasonable be expected to be thrown from error free library code when called by buggy application code. InternalError as its name suggests is meant to be thrown in situations that could only be caused by a bug internal to the runtime. If don't like the idiom new InternalError().initCause(), then add a constructor to InternalError (and perhaps Error also) so that you can pass the cause as a constructor parameter. Just my $0.02 David Daney ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Bryce McKinlay wrote: David Daney wrote: I wonder if we should standardize on using RuntimeException in these cases. A quick grep through the source code shows that we use both InternalError and RuntimeException for these shouldn't/can't happen catch blocks in various cases. I think RuntimeException would be a better choice, since it has a proper cause constructor for re-throwing exceptions. I don't like this idea. RuntimeException is meant to be the base class for Exceptions that can reasonable be expected to be thrown from error free library code when called by buggy application code. InternalError as its name suggests is meant to be thrown in situations that could only be caused by a bug internal to the runtime. If don't like the idiom new InternalError().initCause(), then add a constructor to InternalError (and perhaps Error also) so that you can pass the cause as a constructor parameter. We can't add constructors to InternalError, as that would violate the spec. Which spec. would that be? I am unfamiliar with it. David Daney. ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
David Daney wrote: We can't add constructors to InternalError, as that would violate the spec. Which spec. would that be? I am unfamiliar with it. David Daney. The Java 2(TM) Platform API specification[1] [1] http://java.sun.com/j2se/1.4.2/docs/api/ Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: merge File.toURI() from Classpath
Bryce McKinlay wrote: David Daney wrote: We can't add constructors to InternalError, as that would violate the spec. Which spec. would that be? I am unfamiliar with it. The Java 2(TM) Platform API specification[1] [1] http://java.sun.com/j2se/1.4.2/docs/api/ Does it say somewhere that we cannot add public methods while maintaining compatibility with Sun's implementation? It doesn't seem like a good idea to use an unsuitable exception type just because its API has a slightly more elegant constructor. David Daney. ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
