From: Peter G. <pe...@ar...> - 2007-11-01 18:12:38
|
On Thu, 1 Nov 2007 at 16:41:35 +0100, Marco Antoniotti wrote: > On Oct 31, 2007, at 22:04 , Alex Mizrahi wrote: > > umm, what's about code you've wrote about a month ago: > > > > try > > { > > Interpreter interpreter = Interpreter.createInstance(); > > interpreter.eval("(load \"foo.abcl\")"); > > interpreter.eval("(bar)"); > > } > > catch (Throwable t) > > { > > t.printStackTrace(); > > } > > > > or better (my code): > > > > catch (ConditionThrowable ct) { > > Condition c = ct.getCondition(); > > log (c.writeToString()); > > } > > > > for me this looks as conditions translated to java.. > > or do you mean "conditions translated to java" as translating > > _different_ CL > > conditions to _different_ Java throwables? > > that should be easy to implement on Java side knowing expected > > application > > logics.. > > Hi > > I have not tried that, but if it works it is all I need. Especially > if the ConditionThrowable represents a CL condition with the > appropriate CL object attached. ConditionThrowable extends Throwable. The only classes that extend ConditionThrowable are Go, Return, ThreadDestroyed and Throw, which (except for ThreadDestroyed) are used to represent non-local transfers of control. Throwables of those types should normally be caught in one of the enclosing control frames. SIGNAL, as defined in Primitives.java (line 1475), is the only place where a ConditionThrowable is constructed that wraps a Condition object (apart from Interpreter.java:514, which is j-specific code and not relevant to this discussion). SIGNAL is redefined in signal.lisp, which is explicitly loaded by boot.lisp, so by the time ABCL is up and running, the original definition of SIGNAL from Primitives.java is gone. The new definition of SIGNAL from signal.lisp is pure CL. No ConditionThrowable is thrown. The code I posted a month ago has a catch (ConditionThrowable) clause because Interpreter.eval() is specified to throw a ConditionThrowable, and the code won't compile without the catch clause. REGISTER-JAVA-EXCEPTION is solving the opposite problem: given a Java exception, map it to a CL condition so that the CL condition can be seen on the Lisp side of things when the Java exception is triggered. (Look at the REGISTER-JAVA-EXCEPTION examples in tests/java-tests.lisp.) So I still don't think there's any automatic way of making CL conditions visible on the Java side of things. Unless you wrap things in HANDLER-BIND or HANDLER-CASE, SIGNAL just returns NIL and ERROR lands you in the debugger. But it should be straightforward to use HANDLER-BIND or HANDLER-CASE to intercept the CL conditions you care about and then call Java code that does the right thing for your application's needs on the Java side. Usual disclaimers apply. -Peter |