[armedbear-devel] Serious bug involving UWP

[Erik Huelsmann]

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 at gmail.com> wrote:
> Hi Mark,
>
> On Fri, Sep 18, 2009 at 8:50 AM, Mark Evenson <evenson at 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.
>