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

[David Daney <ddaney at avtrex dot com>]

Bryce McKinlay wrote:
> 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?
> 

Many event loops have the form

for(;;) {
   try { ... } catch(Exception) { /* recover */ }
}

If you throw a RuntimeException, then the application continues.

If you throw an Error, then the application stops.

That is the main difference between the two.  I have never seen it
advocated that event loops catch Errors, ignore them and continue.

If you look at Sun's documentation on ThreadDeath you can see another
reason for not catching Errors in this manner.  OutOfMemoryError is
another example of something that should probably not be caught and ignored.

AssertionErrors are another thing to take a look at.  The designers of
the language thought that if an assertion fails this should be an Error,
not a RuntimeException.

I look at it this way:  These are things that should never happen.  You
should probably be using "assert false", but if you want to wrap the
cause in the thrown error, you need some sort of Throwable where you can
specify this wrapping.  I don't want to downgrade to a RuntimeException
 because this will allow the application to continue.  Some sort of
Error is the only option.  If you don't want to use InternalError, use
the more generic Error, not RuntimeException.


> 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
>