Because by the time a java exception is caught, the stack has already been unwound too far (because java must do so to find the nearest exception handler).
Lisp, basically, keeps track of exception handlers in a table seperate from the runtime stack. Hence, it doesn't need to unwind the stack to find an exception handler - it can just look it up without destroying the existing stack.
And I find this to be a complete pain in the ass. Seriously, you can't even print out variables to see what went wrong when you are building/debugging. They're no longer in scope.
What do you mean by "this" - Java's unwinding of the stack? Because in Lisp you just visit whatever stack frame you want and see everything that's in scope.
The real problem with Lisp environments (at least the open-source ones) is the lack of acceptable modern debuggers.
The fact that my "catch" block is in a different scope than the "try" block. If I really needed to do it, I could subclass "exception" and dump my variables there. But usually I'm just debugging something stupid so it's easier to put in "print" statements.
I've even put in a "macro" that gives me a "print" statement with a long string of "+" afterword so I can quickly spot them in my code and delete them (but don't tell anybody, 'cuz that's just plain wrong...).
Single-stepping, inspection of variables, view source code of current instruction. That's about it. I'm only calling it "modern" to distinguish it from what I'm using, which seems neanderthal.
I know that Slime is supposed to do these things if you use SCBL and various planets align, but (a) I've never gotten it to work, (b) it's obviously no one's priority, and (c) I don't use SBCL much anymore.
Smalltalk does have some advantages over Lisp, including the ones you mention. But lack of a good debugger isn't enough to make me switch. I like Lisp a lot. Besides, switching to Smalltalk would be more work than writing (modernizing, really) a Lisp debugger.
Just steal ideas from the Smalltalk debuggers. You can see their source. If you make a copy of the debugger, you can probably even debug and step through the copy debugger in the debugger.
Lisp, basically, keeps track of exception handlers in a table seperate from the runtime stack. Hence, it doesn't need to unwind the stack to find an exception handler - it can just look it up without destroying the existing stack.