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

[Bryce McKinlay]

C. Brian Jones wrote:

> On Tue, 2004-07-06 at 12:22, David Daney wrote:
>
>  
>
> > 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.
> >    
>
> As pointed out, Classpath does not add to the published, public, API of
> the core classes intentionally for compatibility.  I too think
> RuntimeException would be incorrect in these situations, clearly an
> error should be thrown instead that indicates the dire situation the
> runtime is now in and the need to fix a potential library bug.  The use
> of initCause() would seem appropriate if a cause exists.  
>
> While applications can recover from many forms (maybe all)
> RuntimeExceptions, it is probably impossible to recover from
> InternalErrors.

If a library call failed because of an internal bug that results in a 
RuntimeException being thrown, how is that different from a library call 
that fails because of an internal bug that causes, for example, 
NullPointerException (which extends RuntimeException) to be thrown?

IMO, InternalError should be reserved for virtual machine and low-level 
runtime errors, as suggested by the spec - not generic class library 
bugs as is the case here. InernalError also suggests to me a more 
serious bug than what could be occuring in these situations - ie that 
something is seriously screwed up with the internal state of the 
runtime, whereas a RuntimeException just means that the call failed due 
to a bug in a peice of library code, which is what would be happening 
here if these exceptions ever got thrown.

Its something of a moot point whether an application should be able to 
recover from these or not - they are errors that can/should never 
happen. Even so, it is certainly possible to imagine applications where 
continuing after a failed library call is preferrable to not being able 
to continue at all.

Regards

Bryce