views:

151

answers:

8

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

+1  A: 

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...

Steven A. Lowe
A: 

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.

Vincent McNabb
A: 

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.

tsilb
You can call getStackTrace() on an exception to get the StackTraceElement array for all stack frames (and toString()) those.
Alex Miller
A: 

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

Mark Cidade
A: 

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).

18Rabbit
How do you run in prod with debug disabled but get your debug messages when there is an error?
James A. N. Stauffer
+1  A: 

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.

Sean
+1  A: 

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.

GaZ
Then your code has to catch and log every exception in order to get that data.
James A. N. Stauffer
+1  A: 

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.

kd304
NPE was just an example. The idea relates to all Throwables.
James A. N. Stauffer
Don't know. If you are throwing the exception programmatically include the relevant object values in the message or create a custom exception class to hold them: throw new IllegalArgumentException("obj is " + obj + " instead of X");
kd304
The relevant info is probably higher in the stack so that won't work.
James A. N. Stauffer