Sorry I should said
Go & Return -> ControlTransfer - > RuntimeException Throw -> RuntimeCondition -> RuntimeException
Though some people use Throw for for flow control
----- Original Message ----- From: dmiles@users.sourceforge.net To: "Erik Huelsmann" ehuels@gmail.com; "Armed Bear" armedbear-devel@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:
ControlTransfer RuntimeCondition
Derive them both from RuntimeException if you'd like.
----- Original Message ----- From: "Erik Huelsmann" ehuels@gmail.com To: "Armed Bear" armedbear-devel@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:
- ConditionThrowable is the most undescriptive name of what it actually is and
- Since ConditionThrowable is a completely *internal* thing to ABCL,
it's wrong to expose it this way
My proposal is to:
- 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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Fri, 6 Nov 2009 19:42:00 -0800 logicmoo@gmail.com wrote:
Sorry I should said
Go & Return -> ControlTransfer - > RuntimeException Throw -> RuntimeCondition -> RuntimeException
Though some people use Throw for for flow control
Throw (in Common Lisp) is for flow control. There is no explicit control operator associated with conditions, just the interface functions (error signal, etc). In fact, I think Pitman's reference implementation of the condition system uses combinations of closures and block/return (or possibly tagbody/go) as opposed to catch/throw.
Matt
armedbear-devel@common-lisp.net
-
logicmoo＠gmail.com -
Matthew D. Swank