File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes Capturing more information in a Java Stack Trace Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Capturing more information in a Java Stack Trace" Watch "Capturing more information in a Java Stack Trace" New topic

Capturing more information in a Java Stack Trace

Promod kumar
Ranch Hand

Joined: Jun 26, 2006
Posts: 90
When I get a Java Stack trace, I get all the methods called. What I would like to get is all the methods along with all the method argument values and local variable values.
I used to be a Smalltalk programmer and the stack trace there would give all that info. It basically executed something like toString on all the objects and put that information in the stack trace.
I looked at StackTraceElement and it only has the following attributes
private String declaringClass;
private String methodName;
private String fileName;
private int lineNumber;
Is this the reason I cannot get access to other things in a method. Is this the way it is going to be until Sun fixes it. We use IBM JVM, can I ask them to fix this for me.
Are there any other solutions.
Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
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 ]

"I'm not back." - Bill Harding, Twister
Ernest Friedman-Hill
author and iconoclast

Joined: Jul 08, 2003
Posts: 24199

There is the Omniscient debugger which, although it doesn't do precisely that, gives you the same end result. If you've got the RAM, it's got the info!

[Jess in Action][AskingGoodQuestions]
Promod kumar
Ranch Hand

Joined: Jun 26, 2006
Posts: 90
Thanks a lot for your replies. I did not mean to sound like I was complaining about a bug, I definitely think it would be an awesome feature/enhancement to have. With the current stack, sometimes you end up speculating or making educated guesses about what could be causing the problem and the additional information will definitely help or decrease the speculation.

I will look into some of the things you mentioned along with talking to our vendor to see if they want to take this up.
I agree. Here's the link:
subject: Capturing more information in a Java Stack Trace
It's not a secret anymore!