Bob Rogers wrote:
Yes, once we have the ability to have exception handlers only handle
specific types of exceptions, then they'll allow all other types of
exceptions to pass through. (Which means we won't end up with the
infinite exception handler loops we currently get if exception handlers
aren't disabled as soon as they're used.)
Are you sure? What if the body of a catch-all error handler signals an
error? Methinks the handler must truly be taken out of scope before it
is invoked in order to avoid infinite exception handler loops.
Yes, of course a catch-all exception handler will always catch all
exceptions. But, a catch-all exception handler is intended to catch all
exceptions, and therefore can't make any assumptions about the exception
object other than the defined standard exception interface.
The problem now isn't that the same exception handler is being called
twice (once on the first exception, and once on the exception thrown
from within the handler). The problem is that the exception handlers
were written assuming that they'd only ever get one kind of exception.
When they get a different kind of exception the second time, they aren't
expecting it, and make some terrible mistake, which throws another
exception, but they don't know how to handle that one and make a
terrible error and throw another exception, and so get themselves into
an infinite loop.
The 'can_handle' method is the only required interface for checking
whether a particular handler will accept a particular exception. All
other checks should be hidden behind that method.
Hmm. The only way to find out whether a Lisp handler will handler a
given exception is to call it; if the answer is yes, it will never
return. So I'm hoping a 'can_handle' method that either returns false
or transfers control to somewhere else can be made to work.
For that, you would implement a catch-all handler (completely ignoring
'can_handle'), and then rethrow any exceptions you can't handle.
Allison