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

[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