There's probably a better way to do this, but I have been having a difficult time trying to, from the lisp side of things, track down the cause of errors signaled from java code.
It turns out that we can use lisp's normal error handling facilities to work with java errors. The following snippet triggers a java NullPointerException and if we just evaluate this in SLIME we don't actually see the java backtrace (or at least I don't see it -- of course it would be nice if there were a way to do so).
(handler-case ;; this will throw an NPE (java:jstatic-raw "getenv" "java.lang.System" nil) (error (e) ;; this prints the stack trace to the jvm's standard out, which ;; when running under slime, is our *inferior-lisp* buffer. (print (#"printStackTrace" (java:java-exception-cause e)))))
But this isn't so great as the stack trace is printed to the inferior-lisp buffer. To see it in SLIME's output buffers, we can use ABCL's getMessage routine as follows:
(handler-case ;; this will throw an NPE (java:jstatic-raw "getenv" "java.lang.System" nil) (error (e) ;; this prints the exception type and the stack trace to SLIME's STDOUT (print (#"getMessage" e))))
Having this certainly makes it easier to find the source of errors in java code called from ABCL.