1

When a multi-step single line statement results in a NullPointerException (NPE), the stack trace indicates the line number where the NPE was thrown. Is it possible for the JVM to provide any additional information at all in the NPE message to narrow down which statement on the line actually resulted in the NPE?

E.g.

myObject.getSomeField().doSomething();

Either myObject or myObject.getSomeField() could be null, and both would result in the same stack trace. Is it technically possible for the JVM to provide additional information here to help reduce the ambiguity?

There are many ways to avoid this in code, ranging from simply spreading the steps across multiple lines:

myObject
    .getSomeField()
        .doSomething();

to checking for null and handling appropriately at each step:

if (myObject != null)
{        
    SomeField myField = myObject.getSomeField();
    if (myField != null)
    {
        ...

as well as solutions using the ternary operator or other shortcuts.

However, for this question I am strictly concerned with what the JVM can do based on the information it already has available to it. Does the JVM have additional information that it could include in the NPE message to mitigate any uncertainty?

Trevor Freeman
  • 7,112
  • 2
  • 21
  • 40
  • The JVM could identify the bytecode offset where the error originated, and the compiler might then be able to map it to a value. But very often the error arises in an API, where one of the user-supplied parameters was bogus. And there's no particularly obvious way to tie an error back to a parameter and from there to the expression that generated the parameter value. – Hot Licks Aug 26 '13 at 22:27
  • @HotLicks I was thinking more along the lines that the JVM must know how many steps deep it is on a line. It knows which steps map to which lines, and I was curious if it could in theory determine it was on step 2 (regardless of actual name/variable of the step), and just report that in the NPE message for you to figure out on your own. In the face of any re-orderings or optimizations though, I suppose it could be greatly misleading. – Trevor Freeman Aug 26 '13 at 22:33
  • Would like to have this question considered for reopening since the linked question is asking if the JVM can provide the variable name that was null (and the answer is negative), whereas this question is asking if the JVM has **any** information that could be added to the NPE message to mitigate the ambiguity (e.g. "statement 2 on the line was null"). – Trevor Freeman Aug 26 '13 at 22:38
  • The answer is the same. No. See also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4834738 ... and note how long it has been open. – Stephen C Aug 26 '13 at 23:08
  • @StephenC I imagine that you are correct, and I think that should be an actual answer which could be upvoted and/or accepted if this question is reopened (since I believe the questions are indeed different, and that this question has an expanded scope). – Trevor Freeman Aug 26 '13 at 23:21
  • @StephenC Great bug link, and I like the evaluation comment: "Will look into this in tiger.." I guess something else came up ;-) – Trevor Freeman Aug 26 '13 at 23:27
  • "How many steps" would mean bytecode offset. And, actually, the JVM already identifies this, since line numbers are pretty meaningless to the JVM. But, as I said, having a bytecode offset does little good, both because the compiler doesn't keep that granularity of bytecode mapping, and because more often than not the bug and it's detection are separated by a number of bytecodes, if not several method calls. – Hot Licks Aug 27 '13 at 04:03

0 Answers0