[armedbear-devel] Review of exception handling ["catch (Throwable"]

[Ville Voutilainen]

2009/12/28 Erik Huelsmann <ehuels at gmail.com>:
> I imagine that with the right enhancement construct in the
> interpreter/compiler, we could inject well specified points in our
> code where Java exceptions get converted to Lisp errors.
> If we decide to go that way however, a new question arises: what to do
> if the handler-bind *doesn't* bind the specific error? Should the Lisp
> mechanism kick in? (that is: pass the error to outer handlers) or
> should the original error be rethrown?

Well, if an error is unhandled with the current implementation, we land in the
debugger, right? What I'd like to have is some means to tell abcl whether
the debugger or a rethrow is wanted. Lisp programs don't really have any
option besides the debugger, other than terminating (and we might want
to support that too), but java programs embedding lisp programs
may be capable of recovering from exceptions/errors unhandled on the lisp
side.

As hopefully captured by your recap of my irc comments, I think ignore-errors
should catch everything, and not leak. Same goes for casing/binding
serious-condition
(or condition, obviously, since it's the base type). We then have to
decide what role
java-condition plays, and I think we should keep it as a means to
handle exceptions
raised by java functions that are called from lisp code. That's a bit
vague, obviously,
since it's then hard to draw the line as to whether a RuntimeException manifests
as java-exception or as a condition. The answer to that line-drawing depends on
whether we have a condition type for StackOverflow and NPE and NoMemory.
I'm inclined to think that the aforementioned exceptions map to java-condition.
The base types of java-exception are then enough for more lispy code, and I
think print methods take care of serializing into string format if need be.

Did that make sense?