[armedbear-devel] Changes to ConditionThrowable

[logicmoo at gmail.com]

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/ScriptEngines/ABCLInterpreter.cs

Thanks for he clarity.


----- Original Message ----- 
From: "Erik Huelsmann" <ehuels at gmail.com>
To: <dmiles at 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 at 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.