Would it be useful to add extra info to stack traces?

Question

Would it be useful to be able to mark objects where the value ofString.valueOf() would included in any stack trace. In my example below I used "trace". Variables that aren't declared at the point of the stack trace would just be ingored. It would make debugging much easier and make it much easier to write programs that are easy to debug.

Example stack trace for the code below:

java.lang.NullPointerException:
    at Test.main(Test.java:7) index=0, sum=3, obj=null


public class Test {
  Object obj;
  public void main(String[] args) trace obj {
    trace int sum = 0;
    for(trace int index = 0; index < args.length; index++) {
      sum += Integer.parseInt(args[index]);
      sum += obj.hashCode();//Will cause NullPointerException
    }
  }
}

From: http://jamesjava.blogspot.com/2005/04/extra-info-in-stack-traces.html

Answer 1

this might be useful, but i think it clutters the code - presumably when the code is working you would want to remove the 'trace' keywords; perhaps some form of metadata would be more appropriate

then there's always print statements...

Answer 2

Yes, it can be quite useful. I often do this kind of thing myself, but I only have it compile into non-production code, usually.

Answer 3

What I'd love is a property of the exception which would be a string array of all the method signatures leading up to the throw... without having to parse it out of the Exception text.

Answer 4

The Visual Studio C# debugger's call stack window includes a stack trace with all the argument values displayed.

Answer 5

Eh. Personally I don't think it would be that useful. If I'm running my code and hitting exceptions I can more easily set a breakpoint and step into the code and see what all of the variables are at that point and figure out where it's really breaking.

Using this trace method not only would I have to keep adding and removing keywords from in front of variables as I worked on different bugs but I don't think that it would be any real improvement over just adding good logging/debugging messaging (which is much easier to remove or disable when pushed to production).

Answer 6

Tempting, but I don't think this feature warrants a new keyword in Java (and that much more complexity in the language).

I've found the use of Throwable.printStackTrace has usually been plenty to quickly point to the problems that need my attention.

Answer 7

Perhaps I'm missing the point, but why not use a proper logging framework (e.g. Log4j)? Then you can use nested / mapped diagnostic contexts (NDC / MDC) for outputting variable values.

Answer 8

I would rather prefer a standard (annotation based) way of describing the programmers intent for nullness (FindBugs, JSR 305). I once considered having not just the line number, but the column number included in the exception message so in long chained invocations you could easier see which dot operator caused the NPE. As stated by others in NPE related questions here on StackOverflow, in most cases you get NPE from trying to access a field/method on a null object.