Re: [armedbear-devel] Changes to ConditionThrowable

Yep I had *improperly* tried to divide the three type of ControlTransfers They are indeed undistinguishable by class. In fact my now I remember: 3rd party code didn't catch the ControlTransfers but instead override ERROR/%DEBUGGER-HOOK-FUNCTION Symbol sym = Lisp.PACKAGE_CL_USER.findAccessibleSymbol("ERROR"); sym.setSymbolFunction(new CSThrowError(sym.getSymbolFunction())); sym = Lisp.PACKAGE_SYS.findAccessibleSymbol("%DEBUGGER-HOOK-FUNCTION"); sym.setSymbolFunction(new CSThrowError(sym.getSymbolFunction())); Then had to decide to handle it with inspecting the arguments with lines: 32-54 of http://code.google.com/p/opensim4opencog/source/browse/trunk/Cogbot/ScriptEn... Thanks for he clarity. ----- Original Message ----- From: "Erik Huelsmann" <ehuels@gmail.com> To: <dmiles@users.sourceforge.net> Sent: Friday, November 06, 2009 11:39 PM Subject: Re: [armedbear-devel] Changes to ConditionThrowable Hi Douglas, On Sat, Nov 7, 2009 at 1:33 AM, <logicmoo@gmail.com> wrote:
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.
The thing is: SeriousCondition is never thrown in terms of Java 'throw': it's either signalled or error-ed, which don't use the Java throw primitive. I think these conditions really *are* transfer-of-control events. Thanks for your feedback! Bye, Erik.
participants (1)
-
logicmoo@gmail.com