On Thu, Dec 17, 2009 at 8:50 PM, Peter Olsen pcolsen@gmail.com wrote:
Ladies and Gentlemen,
I'm writing to ask how to handle exceptions generated in Java code called from ABCL.
I'm part of a group trying to combine an existing Common Lisp back-end with an existing Java front end. We've pretty much decided that ABCL is the best way to do that, using Alan Ruttenberg's Java Syntax Solution to make Java calls back to the front-end from Lisp.
One problem we're facing is how to handle gracefully exceptions generated in Lisp code called from Java. In our case, we'll need to make calls back to the Java front-end to get user information and to display results. Some of these calls throw exceptions. What is the best way to catch these?
I'm not sure I've understood what you want. If you need to handle in Lisp exceptions thrown by Java code, using the standard Common Lisp condition facilities, you can use the primitive (register-java-exception class-name condition-class), where class-name is a string naming a Java exception class and condition-class is a symbol naming a Lisp condition, which must be a subclass of java-exception. Every time a Java call is made that throws a registered exception, the corresponding Lisp condition is signaled. IIRC if you don't register any exception that way, all exceptions are remapped to a generic condition of type java-exception. If instead you want to handle in Java conditions signaled by Lisp code, you can use the debugger hook to replace ABCL's debugger with a function that throws a Java exception. ABCL includes such a function (afaik it was used in the J editor): sys::%debugger-hook-function. Of course you won't be able to use CL restarts from Java with exceptions thrown by this debugger hook, since throwing a Java exception always unwinds the stack.
I'd also like any thoughts on the comparative advantages of using the JSS as opposed to the native ABCL calls.
I have never used JSS, and didn't even know it existed. I'm aware of an invoke.lisp with supposedly similar functionality but with the drawback of requiring an additional Java library. I also wrote my little, less powerful Java easy access layer for a project of mine, and I can say that having nicer syntax for Java calls improves code readability quite a lot. On the other hand, if you need the maximum efficiency (i.e. no more runtime dispatch than what Java itself does, plus the necessary reflection overhead), ABCL's native calls are the best choice.
hth, Alessio