2009/12/28 Erik Huelsmann <ehuels@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?