[armedbear-devel] Changes to ConditionThrowable
logicmoo at gmail.com
logicmoo at gmail.com
Sat Nov 7 03:42:00 UTC 2009
Sorry I should said
Go & Return -> ControlTransfer - > RuntimeException
Throw -> RuntimeCondition -> RuntimeException
Though some people use Throw for for flow control
----- Original Message -----
From: <dmiles at users.sourceforge.net>
To: "Erik Huelsmann" <ehuels at gmail.com>; "Armed Bear" <armedbear-devel at common-lisp.net>
Sent: Friday, November 06, 2009 4:33 PM
Subject: Re: [armedbear-devel] Changes to ConditionThrowable
> My two cents:
> Those who call Lisp.eval(...) or mySymbol.execute() should at least be capable of catching RuntimeCondition
> But should not be forced to also catch Go and Throw
> The way it is now..
> I have a Primitive that I implement outside of ABCL.
> It catches certain condition throwables but should not have to catch Throw/Go
> which means:
> ABCL calls my primitive.
> My code is calling back into ABCL
> I must catch ConditionThrowable.
> I must also check to see if ConditionThrowable instanceof Go or instanceof Throw.
> If one of these things are true, I have to rethrow the Go or Throw
> However I do not rethrow SeriousCondtions..
> I have a different handler. that may change the type of condition.
> I suggest dividing the ontology of ConditionThrowable into two types:
> Derive them both from RuntimeException if you'd like.
> ----- Original Message -----
> From: "Erik Huelsmann" <ehuels at gmail.com>
> To: "Armed Bear" <armedbear-devel at common-lisp.net>
> Sent: Friday, November 06, 2009 11:49 AM
> Subject: [armedbear-devel] Changes to ConditionThrowable
>>A very prominent item in our API is that nearly every function is
>> declared to throw ConditionThrowable.
>> Personally, I have 2 gripes with that situation:
>> 1) ConditionThrowable is the most undescriptive name of what it actually is and
>> 2) Since ConditionThrowable is a completely *internal* thing to ABCL,
>> it's wrong to expose it this way
>> My proposal is to:
>> 1) Rename ConditionThrowable to ControlTransfer - which is more of a
>> description of what it does: it's used internal to ABCL to cause
>> non-local transfer of control
>> 2) Make ControlTransfer an unchecked exception (thus derive it from
>> RuntimeException), because that'll allow us to keep it from being
>> exposed in the API.
>> We'll need to document in an abcl-embedding manual that callbacks
>> should be aware of the fact that a ControlTransfer exception may cause
>> the function's execution to be terminated.
>> For normal API use, ControlTransfer won't be seen: it'll be thrown and
>> consumed inside ABCL.
>> How about that?
>> armedbear-devel mailing list
>> armedbear-devel at common-lisp.net
More information about the armedbear-devel