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

[Erik Huelsmann]

On Fri, Dec 25, 2009 at 11:50 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
> Last weeks I did a full review of our code base of uses of "catch
> (Throwable" as a means of catching anything and "just continuing from
> there".
>
> It seems our code was relatively unpredictable, because in some sites
> it would throw a debugging exeption, whereas in others processing
> would continue. With the change where ControlTransfer is now an
> unchecked exception, it turns out most of the try/catch blocks were
> unnecessary anyway; most of them have been removed or made more
> specific (IOException, mostly).
>
> The remaining ones seem to have a function, however, everybody is
> invited to see if I didn't forget or misjudge some locations.
>
> With the removal, there's a new instability, it seems: when using the
> IGNORE-ERRORS macro, one expects the code inside it to catch all
> errors and continue processing after it, no matter what the error.
> However, since we no longer catch Throwable and therefore no longer
> catch any of the RuntimeExceptions, it turns out IGNORE-ERRORS leaks
> all runtime exceptions. Arguably it shouldn't leak
> StackOverflowException and many others: these might be *the*
> conditions to continue after IGNORE-ERRORS.
>
> So, I think we need to implement some construct to catch all java
> exceptions raised inside it and convert them to Lisp errors. This can
> then be included in IGNORE-ERRORS.

Through IRC, Ville asks if we need to distinguish between
compiler/interpreter cases of IGNORE-ERRORS. Depending on how we
implement it: possibly.

Then he goes on to state that when you HANDLER-CASE/HANDLER-BIND
SERIOUS-CONDITION (the base type of anything which is normally
non-continuable), then you should probably also catch
RuntimeExceptions: out-of-memory and out-of-stack and others.

He states that binding JAVA-EXCEPTION for any code which calls Java
code should handle them at the very least. Well, I can safely say
that's infact the case. However, if you run out of Java stack
somewhere in the middle of Lisp code, an out-of-stack exception is
generated too, but it's not handled these days by any of the
HANDLER-BIND or IGNORE-ERRORS forms in any of the enclosing/calling
forms. So, my point wasn't as much about our interfacing with Java
code, but more about where to catch errors from Lisp code.

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?

Comments?


Well, it's great to be able to discuss: the outcome should at least be
less random than what we used to see in our code before.


Bye,

Erik.