[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bryce McKinlay
Subject: Re: Patch: merge File.toURI() from Classpath
Date: Tue, 06 Jul 2004 19:23:54 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040626)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]