[armedbear-devel] Catching CL errors in java

Tue Feb 19 17:12:39 UTC 2013

Threads should not be a problem. I have a thread pool (of one thread),
where all evals are executed (had this problem before :) ).

If I do the let version in the repl, I seem to get both an exception and a
CL error. Like this:

CL-USER(1): (let ((*debugger-hook*  #'sys::%debugger-hook-function)) (/ 1
0))
org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp
condition: Arithmetic error DIVISION-BY-ZERO signalled.
        at org.armedbear.lisp.Interpreter$1.execute(Interpreter.java:569)
        at org.armedbear.lisp.LispThread.execute(LispThread.java:653)
        ...stack trace...
#<THREAD "interpreter" {5B6ADD}>: Debugger invoked on condition of type
ERROR
  Caught org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp
condition: Arithmetic error DIVISION-BY-ZERO signalled..

and I get into the debugger.

If I use the setf version in the repl, It throws an exception and exits
(which I think is the behavior I want).

If I use setf with .eval, I get:
Maximum error depth exceeded (11 nested errors) with 'Arithmetic error
DIVISION-BY-ZERO signalled.'.

I have added (/ 1 0) to the eval call, so that happens after eval has been
called 11 times. But the exception never reaches my java code.

Jonathan

On Tue, Feb 19, 2013 at 6:03 PM, Alessio Stalla <alessiostalla at gmail.com>wrote:

> Sorry, to clarify: defparameter is a friend of setf when used like you
> did, which is not how it's normally used (defparameter defines a
> global dynamic variable and, as a side effect, modifies its value if
> it already had one, but you never use it just for its side effect).
> You can imagine defparameter as a shorthand for a defvar followed by a
> setf.
>
> On Tue, Feb 19, 2013 at 6:00 PM, Alessio Stalla <alessiostalla at gmail.com>
> wrote:
> > 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
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20130219/2f1f25e1/attachment.html>