Yes, this information is simply not available under any JDK I'm aware of. When an exception is thrown in one method and then caught several layers up in the stack trace, at that point the local variables in the lower levers of the stack have been lost (to the best of my knowledge).
You can
ask Sun or IBM to "fix" it, maybe by copying the local variable data into the Throwable as part of fillInStackTrace(), but I'm pretty sure they would consider this a
feature request rather than a bug. Sure, it's potentially a very useful feature - but it's also one that could significantly increase the time and memory required by exceptions - and they're already overweight was far as some people are concerned. And frankly, people have done without this in Java for a long time now. Don't expect many people to see this as a necessary
fix of anything. Chances of getting Sun or IBM to implement this are probably slim, in my opinion.
However, note that Sun has been open-sourcing Java lately. Someone could implement this in their own custom JVM, making the source available to others, including Sun. If the code is good, works well and is implemented as an
optional feature (perhaps activated by a command-line argument to the java executable) then it's reasonably possible Sun might incorprate the changes into future releases. Even if they don't, you could still use the custom JVM yourself and release it to others (though it might not be possible to identify it with the Java trademark; not sure there).
Another approach might be to create a workaround using a combination of existing tools. You may be able to use a bytecode manipulation library (such as BCEL, ASM, or AspectJ) to inject calls to new code into existing libraries. E.g. anytime Throwable's fillInStackTrace() is called, insert another call (before or after) to a custom populateLocalVariableCopies() method. (The key being, this needs to be done before the Throwable is thrown, not after it's caught.) This method might work by using the
Java Platform Debugger Architecture to gain access to the stack frame data, and copy it into some sort of data structure where it can be retrieved later. Between the bytecode engineering and the JPDA, this would require a certain amount of custom setup and configuration of the JVM - it would probably be a bit of a pain to deploy this setup to a bunch of different desktops, for example. But it could well be worthwhile to do this for a development machine, for
testing.
If I were going to pursue this, I would probably start with setting up AspectJ and learning how to insert new calls into existing libraries. You can also use this to automatically insert logging statements at the beginning or end of method calls, which you could use to log methods, arguments, and return values. (Buy
AspectJ in Action and check out chapter 5 for more info.) This may be enough for your purposes right there - the logs can tell you much of what you might wish to know. If it's not enough, then continue by investigating how to use JPDA to access the stack frames.
Well, that sounds like a bit of work, but also a fun and useful project. I wonder if anyone's already done something along those lines? Wouldn't surprise me, really.
[ January 10, 2007: Message edited by: Jim Yingst ]