[armedbear-devel] Catching CL errors in java

[Alessio Stalla]

I don't think the package is the culprit. Your package most probably
USEs the CL package, or many other things would not work as you'd
expect.

Answering your earlier question, the correct way would be (setf
*debugger-hook* ...) rather than defparameter, or even better binding
instead of assigning - (let ((*debugger-hook* ...)) (do-your-stuff)).

But I don't think that can make a difference between working and not
working at all. It is more of a question of good style. Perhaps you're
not considering thread-local bindings? If you run your
defparameter/setf form on one thread, but .eval is called on another
thread (and with a GUI involved, that is very probable), then chances
are that the code in your .eval call is running in a dynamic
environment where *debugger-hook* is locally rebound, and thus the
global binding that you modify with defparameter/setf is shadowed. You
can detect it by printing the value of *debugger-hook* in an .eval
call triggered by the GUI. If that is the case, you should make sure
to assign a new value to *debugger-hook* on the right thread, or,
better, to use (let ...) as shown above. Let me stress that using LET
is usually what you want in Lisp, especially when dealing with dynamic
variables; a good rule of thumb is: avoid SETF and friends
(defparameter is a friend) unless you're working on local variables.
Of course, experts know when and how to break the rules :D but if
you're a beginner, sticking to that style will make things easier to
understand and debug, once you enter the right mindset.

hth,
Alessio

On Tue, Feb 19, 2013 at 5:50 PM, Jonathan Fischer Friberg
<odyssomay at gmail.com> wrote:
> It might be that I'm in the wrong package. Although the repl is in cl-user,
> and even if I change to that package the code in the previous mail has no
> effect.
>
> Jonathan
>
>
> On Tue, Feb 19, 2013 at 5:36 PM, Jonathan Fischer Friberg
> <odyssomay at gmail.com> wrote:
>>
>> I don't know if this is the correct way to do it, but I did:
>>
>> (defparameter *debugger-hook*  #'sys::%debugger-hook-function)
>>
>> In the repl (from running java -jar abcl.jar), this worked as expected.
>> However, I can't seem to get it working with the .eval function of my
>> interpreter instance.
>>
>> Jonathan
>>
>>
>> On Tue, Feb 19, 2013 at 5:07 PM, Alessio Stalla <alessiostalla at gmail.com>
>> wrote:
>>>
>>> Short story: if you call into Lisp using the JSR-223 API, conditions
>>> are automatically rethrown as Java exceptions.
>>>
>>> Long story: the way this is implemented is by binding *debugger-hook*
>>> to an internal, probably undocumented function, that already does what
>>> you want. It is called sys::%debugger-hook-function.
>>>
>>> On Tue, Feb 19, 2013 at 4:25 PM, Jonathan Fischer Friberg
>>> <odyssomay at gmail.com> wrote:
>>> > I should add that a solution from inside CL would also work. I'm using
>>> > the
>>> > ABCL eval to execute all code, so maybe I could wrap the call with
>>> > something
>>> > like this:
>>> >
>>> > (handler-case
>>> >    (... do-stuff ...)
>>> >    (... catch CL-condition + throw java exception ...))
>>> >
>>> > I don't know if that would work. Also, my CL skills are not good enough
>>> > to
>>> > finish the code above (how do I capture all conditions?), so help would
>>> > be
>>> > appreciated.
>>> >
>>> > Jonathan
>>> >
>>> >
>>> > On Tue, Feb 19, 2013 at 3:30 PM, Jonathan Fischer Friberg
>>> > <odyssomay at gmail.com> wrote:
>>> >>
>>> >> Hi again, :)
>>> >>
>>> >> I'm currently running CL-code from java. The gui is completely
>>> >> implemented
>>> >> on the java side. It would be nice if all errors occuring inside abcl
>>> >> could
>>> >> be captured from the java side (to be displayed in the gui as an
>>> >> error). Is
>>> >> that possible?
>>> >>
>>> >> Jonathan
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > armedbear-devel mailing list
>>> > armedbear-devel at common-lisp.net
>>> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>>> >
>>>
>>>
>>>
>>> --
>>> Some gratuitous spam:
>>>
>>> http://ripple-project.org Ripple, social credit system
>>> http://villages.cc Villages.cc, Ripple-powered community economy
>>> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
>>> http://code.google.com/p/tapulli my current open source projects
>>> http://www.manydesigns.com/ ManyDesigns Portofino, open source
>>> model-driven Java web application framework
>>
>>
>



-- 
Some gratuitous spam:

http://ripple-project.org Ripple, social credit system
http://villages.cc Villages.cc, Ripple-powered community economy
http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
http://code.google.com/p/tapulli my current open source projects
http://www.manydesigns.com/ ManyDesigns Portofino, open source
model-driven Java web application framework