(Unknown source) in the exception stack trace

Question

Background

This question is related to Why String.valueOf (null) throws 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 a related question, overloading the Java method resolves the above involution to String.valueOf(char[]) , which rightly leads to a NullPointerException at runtime.

Compiled in Eclipse and javac 1.6.0_17 , this is a 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) 

Please note that the KEY information is missing in the stack trace above: it does not have a complete signature of the valueOf method! It just says String.valueOf(Unknown Source) !

In most situations that I have encountered, exception stack traces always have a complete signature of the methods that are actually in the stack trace, which, of course, is very useful for immediately identifying the problem and the main reason why the stack trace (which, of course , quite expensive to build) is provided in the first place.

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

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

• The programmer himself understands that the method is overloaded, and according to the resolution rule in this case, an "incorrect" overload is called
• The programmer uses a good IDE that allows him / her to quickly see which method is selected
  • In Eclipse, for example, when you hover over the above expression, it quickly tells the programmer that String valueOf(char[] data) actually one
• The programmer checks the bytecode (ugh!)

The last option is probably the least accessible, but, of course, the final answer (the programmer may misunderstand the overload rule, the IDE may be a mistake, but bytecodes always (?) Tell the truth about what is being done).

---

Questions

• Why is the stack trace so uninformative in this case regarding the signatures of the methods that are actually in the stack trace?
  • Is it because of the compiler? Lead time? Something else?
• In what other (rare?) Scenarios may the stack trace not capture important information like these?

Answer 1

This is usually due to missing debugging information. You are probably using a JRE (not a JDK) that does not include debugging information for the rt.jar classes. Try using the full JDK, you will get the correct places 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) 

Answer 2

Note that if you use Ant build and if the debug attribute is set to false in the javac command, this can happen.

ex: if you need the correct location in the debug = true trace set in Ant build,

  <javac verbose="false" srcdir="${src}" destdir="${classdir}" debug="true" includes="**/*.java"> <classpath refid="compile.classpath" /> </javac> 

Answer 3

I had the same problem: for continuous integration, I use spring and apache ant .

The error I had was in the build.xml file.

The gender change log with more accurate content was:

build.xml with an error:

  <javac srcdir="${src.home}" destdir="${work.home}/WEB-INF/classes"> <classpath refid="compile.classpath" /> </javac> 

build.xml without errors:

  <javac srcdir="${src.home}" destdir="${work.home}/WEB-INF/classes" debug="true"> <classpath refid="compile.classpath" /> </javac> 

Inside the structure, I did not have the courage to debug = "true"

Answer 4

I ran the code in Eclipse and 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 the JDK), you can debug string 177 in String.java

Answer 5

This happens when there is no debugging (string) information in the source, or the virtual machine is prompted to throw out this information during class loading. Since you have line numbers, this is not a VM parameter, and the String class lacks debugging information.

Answer 6

In Eclipse: Preferences> Java> Installed JREs. The verified entry must have a path inside the JDK, for example. C: \ Program Files (x86) \ Java \ jdk1.7.0_55 \ jre.