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

[David Daney <ddaney at avtrex dot com>]

Bryce McKinlay wrote:
> David Daney wrote:
> 
> 
>>>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.
>> 
>>
> 
> 
> I understand this. But why shouldn't an application be allowed to 
> continue after a failed library call? My earlier point stands: What is 
> the difference between a buggy method that throws a NullPointerException 
> and a buggy method that throws a RuntimeException? None, IMO.

I give you Vector.java:


  public synchronized Object clone()
  {
    try
      {
        Vector clone = (Vector) super.clone();
        clone.elementData = (Object[]) elementData.clone();
        return clone;
      }
    catch (CloneNotSupportedException ex)
      {
        // Impossible to get here.
        throw new InternalError(ex.toString());
      }
  }

You seem to be arguing that RuntimeException would be OK here instead of
InternalError.

I am (of course) arguing that it would not be OK.

David Daney.