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

[Bryce McKinlay <mckinlay at redhat dot com>]

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.

InternalError extends VirtualMachineError, and is documented in the spec 
that it is "Thrown to indicate some unexpected internal error has 
occurred in the Java Virtual Machine.". Its questionable whether generic 
library code such as this can be considered part of the virtual machine.

In any case, the lack of a "cause" constructor for InternalError pretty 
much rules it out for using in these situations - it clearly wasn't 
intended for chaining/rethrowing internal exception.

RuntimeException subclasses are certainly exceptions that are expected 
to be thrown due to bugs in application code incorrectly calling the 
library, but there are also many cases where they could be thrown due to 
bugs in the runtime code. NullPointerException, for example, is a 
RuntimeException subclass. I'm sure I've seen that thrown once or twice 
due to bugs in Classpath ;-)

Regards

Bryce