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

[Bryce McKinlay]

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.

Its up to the application author to determine how robust their 
application must be - as class library developers we should not try to 
force the application to shut down just because we wrote a buggy 
implementation of something. If Errors are not caught, then 
InternalError should be used for problems that are so bad that the 
application could not possibly continue.

The AssertionError case is different, because assertions are typically 
disabled in production systems.

Regards

Bryce