SLIME backend

[Jim White]

Helmut Eller wrote:

>>>  * the JVM ain't a Lisp Machine (and never will be)
>>
>>Well, I know what you're saying, but maybe it will.
> 
> I was mostly thinking about debugging.  Debuggers for Common Lisp
> usually interact with CL's condition system in particular with
> HANDLER-BIND.  But Java's error handling strategy, throwing an
> exception, is rather incompatible with HANDLER-BIND.  This makes it
> very hard to support 'debug-on-error' style debugging.

I think the difficulty mainly lies in having to deal with bytecode 
rather than a nice data structure for code.  try-blocks are compiled 
into little tables that are logically HANDLER-BIND AFAICT.

Also there is the JVM Debugger API, which provides direct access to 
conditions for such things as triggering on any exception and the like.

> On the JVM it's rather difficult to decide if and where an exception
> will be caught without unwinding the stack.  But invoking the debugger
> after unwinding the stack is usually too late, because the most
> interesting frames are those at which the exception was thrown.

I haven't looked to see if anyone has written a stack walker to discover 
which exceptions are caught where, but it is possible AFAIK.

> Python seem to solve this dilemma by including information about local
> variables in exception objects.  The SLIME backend does same, but such
> a strategy is very expensive and will probably never become popular on
> the JVM.

Language-specific is far easier to deal with than general bytecode for 
sure.

The idea I like for dealing with this sort of thing is to use AOP 
(AspectJ) because you can use it to rewrite bytecode behavior in 
practically any manner desired.  And while it is true that performance 
may suffer in some situations, it is a highly flexible approach that 
offers tradeoffs for compile-time vs. load-time weaving and can be 
selective about classes are affected.

> [BTW, I always wonder how expensive fillInStackTrace is.  Is there a
>  trick to make this cheap or is it as expensive as it sounds?]

It's expensive but optional.

In fact the code for fillInStackTrace could be the starting point for a 
fancier version that decorates it with the exceptions that are caught at 
each frame.  Although on second thought, that may not be the case since 
it is probably native code in the JVM.

So if I wanted a stacktrace with exception handlers and didn't want to 
use the Debugger API, I would do the fillInStackTrace, then for each 
frame get the bytecode for the class of the method 
(ClassLoader.findClass), find the call's location in the bytecode using 
the line number table (this only works for clases compiled with debug 
info on of course), then examine the block surrounding that location to 
see if it is enclosed by a try-block.  If there is a try-block then it 
provides a list of the throwable classes that are caught there.

Jim