Re: Patch: merge File.toURI() from Classpath

2004-07-11 Thread Mark Wielaard
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

2004-07-07 Thread Chris Pickett
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

2004-07-07 Thread Stephen Crawley
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

2004-07-07 Thread Andrew Haley
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

2004-07-07 Thread Dalibor Topic
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

2004-07-07 Thread Stephen Crawley


[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

2004-07-06 Thread David Daney
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

2004-07-06 Thread David Daney
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

2004-07-06 Thread Bryce McKinlay
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

2004-07-06 Thread David Daney
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