I created ticket #64 to track the general issue pointed out by Mark.
Bye,
Erik.
On Sun, Oct 18, 2009 at 12:24 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Mark,
On Fri, Sep 18, 2009 at 8:50 AM, Mark Evenson evenson@panix.com wrote:
On 9/17/09 10:36 PM, Tobias C. Rittweiler wrote:
There is another issue I'd like to raise.
The reason for the funny behaviour, and why it consumed a lot of time to track this bug down is because there's no global handler which prints a Stack Trace for uncaught Exceptions.
Instead of such a global handler, local "catch (...) { Debug.Trace ... }" are sprinkled all over the code base. And, obviously, they're easy to miss---as it has been the case here.
So the exception is swept under the carpet and ABCL seems to unwind the stack to some safe point, probably the toplevel, and proceed from there.
Acknowledged.
The current codebase seemingly suffers from a lack of a coherent plan for how to deal with exceptions, at least to my understanding of it. I think the use of 'org.armedbear.lisp.ConditionThrowable' subclassing 'java.lang.Throwable' should be reconsidered, to make more consistent use of the [exception chaining mechanism introduced in Java 1.4][1].
I've thought about that for a bit, but I don't understand what you mean. Do we agree that ConditionThrowable is the superclass to Go, Return, Throw and ThreadDestroyed only? (And not to any of the Lisp exceptions.)
But going through the code to remove all the instances of swallowing exceptions to at least print diagnostic information should be rather easily gathered low hanging fruit.
The ConditionThrowable should probably be named TransferOfControl instead, is what I'm now thinking. That would add to the "self-explanatory" level in the sources, I'd say.
Bye,
Erik.