views:

82

answers:

4

Background

This question is related to Why does String.valueOf(null) throw a NullPointerException?

Consider the following snippet:

public class StringValueOfNull {
    public static void main(String[] args) {
        String.valueOf(null);

        // programmer intention is to invoke valueOf(Object), but instead
        // code invokes valueOf(char[]) and throws NullPointerException
    }
}

As explained in the answer to the linked question, Java's method overloading resolves the above invokation to String.valueOf(char[]), which rightfully results in a NullPointerException at run-time.

Compiled in Eclipse and javac 1.6.0_17, this is the stack trace:

Exception in thread "main" java.lang.NullPointerException
        at java.lang.String.<init>(Unknown Source)
        at java.lang.String.valueOf(Unknown Source)
        at StringValueOfNull.main(StringValueOfNull.java:3)

Note that the stack trace above is missing the KEY information: it does NOT have the full signature of the valueOf method! It just says String.valueOf(Unknown Source)!

In most situations I've encountered, exception stack traces always have the complete signature of the methods that are actually in the stack trace, which of course is very helpful in identifying the problem immediately and a major reason why the stack trace (which needless to say is rather expensive to construct) is provided in the first place.

And yet, in this case, the stack trace does not help at all. It has failed miserably in helping the programmer identify the problem.

As is, I can see 3 ways that a programmer can identify the problem with the above snippet:

  • Programmer realizes on his/her own that the method is overloaded, and by resolution rule, the "wrong" overload gets invoked in this case
  • Programmer uses a good IDE that allows him/her to quickly see which method is selected
    • In Eclipse, for example, mouse-hovering on the above expression quickly tells programmer that the String valueOf(char[] data) is indeed the one selected
  • Programmer examines the bytecode (ugh!)

The last option is probably the least accessible, but of course is the Ultimate Answer (a programmer may misunderstood the overloading rule, IDE may be buggy, but bytecodes always(?) tell the truth on what's being done).


The questions

  • Why is the stack trace so uninformative in this case with regards to the signatures of the methods that are actually in the stack trace?
    • Is this due to the compiler? The runtime? Something else?
  • In what other (rare?) scenarios can the stack trace fail to capture essential information like these?
+6  A: 

This is normally related to missing debug information. You are probably using JRE (not JDK), which does not include debug information for rt.jar classes. Try using full JDK, you'll get proper locations in the stack trace:

Exception in thread "main" java.lang.NullPointerException
    at java.lang.String.<init>(String.java:177)
    at java.lang.String.valueOf(String.java:2840)
    at StringValueOfNull.main(StringValueOfNull.java:3)
unbeli
A: 

This is not an answer; at best it's an appendix to the question. I decided to move it to CW-answer instead so not to clutter the (already long) question.

This is the output of javap -c StringValueOfNull

Compiled from "StringValueOfNull.java"
public class StringValueOfNull extends java.lang.Object{
public StringValueOfNull();
Code:
 0:   aload_0
 1:   invokespecial   #8; //Method java/lang/Object."<init>":()V
 4:   return

public static void main(java.lang.String[]);
Code:
 0:   aconst_null
 1:   invokestatic #16; //Method java/lang/String.valueOf:([C)Ljava/lang/String;
 4:   pop
 5:   return

}

Method java/lang/String.valueOf:([C)Ljava/lang/String; of course is the bytecode level descriptor for String valueOf(String char[]).

This confirms that indeed, the valueOf(char[]) is the one that gets selected.

polygenelubricants
+3  A: 

Hi, I ran the code in Eclipse and I got the following output,

public class Aloof {
    public static void main(String[] args) {
        String.valueOf(null);
    }
}

Exception in thread "main" java.lang.NullPointerException
    at java.lang.String.<init>(String.java:177)
    at java.lang.String.valueOf(String.java:2840)
    at mysql.Aloof.main(Aloof.java:19)

If you include the full source (from JDK), you can actually debug to the line 177 in String.java

Bragboy
+1  A: 

This happens when there is no debug (line) information in the source or the VM is told to throw that information away at class loading time. Since you have some line numbers, it's not the VM setting but the class String is missing debug information.

Aaron Digulla