[armedbear-devel] Changes to ConditionThrowable

logicmoo at gmail.com logicmoo at gmail.com
Sat Nov 7 00:33:47 UTC 2009


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:

ControlTransfer
RuntimeCondition 

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?
> 
> Bye,
> 
> 
> Erik.
> 
> _______________________________________________
> armedbear-devel mailing list
> armedbear-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel




More information about the armedbear-devel mailing list