<div dir="ltr">I got it. :D<br><br>It was my thread pool that tricked me. Apparently, if there's an exception in a thread pool, it won't be printed or anything, it will just disappear (unless specifically catched).<br>
I tried to catch 'Exception', but the thrown exception is not actually a subclass of 'Exception', it's a subclass of 'Error'! So the exception escaped my catch<br>clause, and because the code was running inside the thread pool, it would not be displayed. So I changed the class to catch to 'Throwable' and now it's working<br>
as it's supposed to (with the let method).<br><br>Thanks for all your help Alessio! :D<br><br>Jonathan </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 6:23 PM, Alessio Stalla <span dir="ltr"><<a href="mailto:alessiostalla@gmail.com" target="_blank">alessiostalla@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Feb 19, 2013 at 6:12 PM, Jonathan Fischer Friberg<br>
<<a href="mailto:odyssomay@gmail.com">odyssomay@gmail.com</a>> wrote:<br>
> Threads should not be a problem. I have a thread pool (of one thread), where<br>
> all evals are executed (had this problem before :) ).<br>
><br>
> If I do the let version in the repl, I seem to get both an exception and a<br>
> CL error. Like this:<br>
><br>
> CL-USER(1): (let ((*debugger-hook*  #'sys::%debugger-hook-function)) (/ 1<br>
> 0))<br>
> org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp condition:<br>
> Arithmetic error DIVISION-BY-ZERO signalled.<br>
>         at org.armedbear.lisp.Interpreter$1.execute(Interpreter.java:569)<br>
>         at org.armedbear.lisp.LispThread.execute(LispThread.java:653)<br>
>         ...stack trace...<br>
> #<THREAD "interpreter" {5B6ADD}>: Debugger invoked on condition of type<br>
> ERROR<br>
>   Caught org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp<br>
> condition: Arithmetic error DIVISION-BY-ZERO signalled..<br>
><br>
> and I get into the debugger.<br>
<br>
</div>That's correct, because the Java exception is caught by the REPL and<br>
turned again into a Lisp condition. Your debugger hook is only in<br>
effect inside the LET, what happens "outside" is under the control of<br>
the REPL.<br>
<div class="im"><br>
> If I use the setf version in the repl, It throws an exception and exits<br>
> (which I think is the behavior I want).<br>
<br>
</div>In this case, you globally override the default REPL behaviour, and<br>
that's why it exits.<br>
<div class="im"><br>
> If I use setf with .eval, I get:<br>
> Maximum error depth exceeded (11 nested errors) with 'Arithmetic error<br>
> DIVISION-BY-ZERO signalled.'.<br>
><br>
> I have added (/ 1 0) to the eval call, so that happens after eval has been<br>
> called 11 times. But the exception never reaches my java code.<br>
<br>
</div>I cannot explain that! And I cannot explain your subsequent message,<br>
either. Maybe you've hit a bug? Anyone has an idea?<br>
<span class="HOEnZb"><font color="#888888"><br>
Alessio<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> Jonathan<br>
><br>
><br>
> On Tue, Feb 19, 2013 at 6:03 PM, Alessio Stalla <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Sorry, to clarify: defparameter is a friend of setf when used like you<br>
>> did, which is not how it's normally used (defparameter defines a<br>
>> global dynamic variable and, as a side effect, modifies its value if<br>
>> it already had one, but you never use it just for its side effect).<br>
>> You can imagine defparameter as a shorthand for a defvar followed by a<br>
>> setf.<br>
>><br>
>> On Tue, Feb 19, 2013 at 6:00 PM, Alessio Stalla <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>><br>
>> wrote:<br>
>> > I don't think the package is the culprit. Your package most probably<br>
>> > USEs the CL package, or many other things would not work as you'd<br>
>> > expect.<br>
>> ><br>
>> > Answering your earlier question, the correct way would be (setf<br>
>> > *debugger-hook* ...) rather than defparameter, or even better binding<br>
>> > instead of assigning - (let ((*debugger-hook* ...)) (do-your-stuff)).<br>
>> ><br>
>> > But I don't think that can make a difference between working and not<br>
>> > working at all. It is more of a question of good style. Perhaps you're<br>
>> > not considering thread-local bindings? If you run your<br>
>> > defparameter/setf form on one thread, but .eval is called on another<br>
>> > thread (and with a GUI involved, that is very probable), then chances<br>
>> > are that the code in your .eval call is running in a dynamic<br>
>> > environment where *debugger-hook* is locally rebound, and thus the<br>
>> > global binding that you modify with defparameter/setf is shadowed. You<br>
>> > can detect it by printing the value of *debugger-hook* in an .eval<br>
>> > call triggered by the GUI. If that is the case, you should make sure<br>
>> > to assign a new value to *debugger-hook* on the right thread, or,<br>
>> > better, to use (let ...) as shown above. Let me stress that using LET<br>
>> > is usually what you want in Lisp, especially when dealing with dynamic<br>
>> > variables; a good rule of thumb is: avoid SETF and friends<br>
>> > (defparameter is a friend) unless you're working on local variables.<br>
>> > Of course, experts know when and how to break the rules :D but if<br>
>> > you're a beginner, sticking to that style will make things easier to<br>
>> > understand and debug, once you enter the right mindset.<br>
>> ><br>
>> > hth,<br>
>> > Alessio<br>
>> ><br>
>> > On Tue, Feb 19, 2013 at 5:50 PM, Jonathan Fischer Friberg<br>
>> > <<a href="mailto:odyssomay@gmail.com">odyssomay@gmail.com</a>> wrote:<br>
>> >> It might be that I'm in the wrong package. Although the repl is in<br>
>> >> cl-user,<br>
>> >> and even if I change to that package the code in the previous mail has<br>
>> >> no<br>
>> >> effect.<br>
>> >><br>
>> >> Jonathan<br>
>> >><br>
>> >><br>
>> >> On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg<br>
>> >> <<a href="mailto:odyssomay@gmail.com">odyssomay@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> I don't know if this is the correct way to do it, but I did:<br>
>> >>><br>
>> >>> (defparameter *debugger-hook*  #'sys::%debugger-hook-function)<br>
>> >>><br>
>> >>> In the repl (from running java -jar abcl.jar), this worked as<br>
>> >>> expected.<br>
>> >>> However, I can't seem to get it working with the .eval function of my<br>
>> >>> interpreter instance.<br>
>> >>><br>
>> >>> Jonathan<br>
>> >>><br>
>> >>><br>
>> >>> On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla<br>
>> >>> <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> Short story: if you call into Lisp using the JSR-223 API, conditions<br>
>> >>>> are automatically rethrown as Java exceptions.<br>
>> >>>><br>
>> >>>> Long story: the way this is implemented is by binding *debugger-hook*<br>
>> >>>> to an internal, probably undocumented function, that already does<br>
>> >>>> what<br>
>> >>>> you want. It is called sys::%debugger-hook-function.<br>
>> >>>><br>
>> >>>> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg<br>
>> >>>> <<a href="mailto:odyssomay@gmail.com">odyssomay@gmail.com</a>> wrote:<br>
>> >>>> > I should add that a solution from inside CL would also work. I'm<br>
>> >>>> > using<br>
>> >>>> > the<br>
>> >>>> > ABCL eval to execute all code, so maybe I could wrap the call with<br>
>> >>>> > something<br>
>> >>>> > like this:<br>
>> >>>> ><br>
>> >>>> > (handler-case<br>
>> >>>> >    (... do-stuff ...)<br>
>> >>>> >    (... catch CL-condition + throw java exception ...))<br>
>> >>>> ><br>
>> >>>> > I don't know if that would work. Also, my CL skills are not good<br>
>> >>>> > enough<br>
>> >>>> > to<br>
>> >>>> > finish the code above (how do I capture all conditions?), so help<br>
>> >>>> > would<br>
>> >>>> > be<br>
>> >>>> > appreciated.<br>
>> >>>> ><br>
>> >>>> > Jonathan<br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg<br>
>> >>>> > <<a href="mailto:odyssomay@gmail.com">odyssomay@gmail.com</a>> wrote:<br>
>> >>>> >><br>
>> >>>> >> Hi again, :)<br>
>> >>>> >><br>
>> >>>> >> I'm currently running CL-code from java. The gui is completely<br>
>> >>>> >> implemented<br>
>> >>>> >> on the java side. It would be nice if all errors occuring inside<br>
>> >>>> >> abcl<br>
>> >>>> >> could<br>
>> >>>> >> be captured from the java side (to be displayed in the gui as an<br>
>> >>>> >> error). Is<br>
>> >>>> >> that possible?<br>
>> >>>> >><br>
>> >>>> >> Jonathan<br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> ><br>
>> >>>> > _______________________________________________<br>
>> >>>> > armedbear-devel mailing list<br>
>> >>>> > <a href="mailto:armedbear-devel@common-lisp.net">armedbear-devel@common-lisp.net</a><br>
>> >>>> ><br>
>> >>>> > <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel</a><br>
>> >>>> ><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> --<br>
>> >>>> Some gratuitous spam:<br>
>> >>>><br>
>> >>>> <a href="http://ripple-project.org" target="_blank">http://ripple-project.org</a> Ripple, social credit system<br>
>> >>>> <a href="http://villages.cc" target="_blank">http://villages.cc</a> Villages.cc, Ripple-powered community economy<br>
>> >>>> <a href="http://common-lisp.net/project/armedbear" target="_blank">http://common-lisp.net/project/armedbear</a> ABCL, Common Lisp on the JVM<br>
>> >>>> <a href="http://code.google.com/p/tapulli" target="_blank">http://code.google.com/p/tapulli</a> my current open source projects<br>
>> >>>> <a href="http://www.manydesigns.com/" target="_blank">http://www.manydesigns.com/</a> ManyDesigns Portofino, open source<br>
>> >>>> model-driven Java web application framework<br>
>> >>><br>
>> >>><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Some gratuitous spam:<br>
>> ><br>
>> > <a href="http://ripple-project.org" target="_blank">http://ripple-project.org</a> Ripple, social credit system<br>
>> > <a href="http://villages.cc" target="_blank">http://villages.cc</a> Villages.cc, Ripple-powered community economy<br>
>> > <a href="http://common-lisp.net/project/armedbear" target="_blank">http://common-lisp.net/project/armedbear</a> ABCL, Common Lisp on the JVM<br>
>> > <a href="http://code.google.com/p/tapulli" target="_blank">http://code.google.com/p/tapulli</a> my current open source projects<br>
>> > <a href="http://www.manydesigns.com/" target="_blank">http://www.manydesigns.com/</a> ManyDesigns Portofino, open source<br>
>> > model-driven Java web application framework<br>
>><br>
>><br>
>><br>
>> --<br>
>> Some gratuitous spam:<br>
>><br>
>> <a href="http://ripple-project.org" target="_blank">http://ripple-project.org</a> Ripple, social credit system<br>
>> <a href="http://villages.cc" target="_blank">http://villages.cc</a> Villages.cc, Ripple-powered community economy<br>
>> <a href="http://common-lisp.net/project/armedbear" target="_blank">http://common-lisp.net/project/armedbear</a> ABCL, Common Lisp on the JVM<br>
>> <a href="http://code.google.com/p/tapulli" target="_blank">http://code.google.com/p/tapulli</a> my current open source projects<br>
>> <a href="http://www.manydesigns.com/" target="_blank">http://www.manydesigns.com/</a> ManyDesigns Portofino, open source<br>
>> model-driven Java web application framework<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Some gratuitous spam:<br>
<br>
<a href="http://ripple-project.org" target="_blank">http://ripple-project.org</a> Ripple, social credit system<br>
<a href="http://villages.cc" target="_blank">http://villages.cc</a> Villages.cc, Ripple-powered community economy<br>
<a href="http://common-lisp.net/project/armedbear" target="_blank">http://common-lisp.net/project/armedbear</a> ABCL, Common Lisp on the JVM<br>
<a href="http://code.google.com/p/tapulli" target="_blank">http://code.google.com/p/tapulli</a> my current open source projects<br>
<a href="http://www.manydesigns.com/" target="_blank">http://www.manydesigns.com/</a> ManyDesigns Portofino, open source<br>
model-driven Java web application framework<br>
</div></div></blockquote></div><br></div>