（未知来源）在异常堆栈跟踪

问题描述

考虑以下代码段：

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

如链接问题的答案所述，Java的方法重载将上述调用解析为，它在运行时正确地导致$ code> 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.

在Eclipse中编译和 javac 1.6.0_17 ，这是堆栈跟踪：

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)

请注意，上面的堆栈跟踪是mi使用 KEY 信息：它确实不具有 valueOf 方法的完整签名！它只是说 String.valueOf（Unknown Source）！

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:

• 程序员意识到自己的方法是重载的，通过解决规则，在这种情况下调用错误的重载


• 程序员使用了一个很好的IDE，可以让他/她快速查看选择哪种方法
  
  
  
  
  • 在Eclipse中，例如鼠标在上述表达式上，快速告诉程序员， String valueOf（char [] data）确实是选定的
  
  
  • 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

    最后一个选项可能是最不方便，但是当然是终极答案（程序员可能误解了超载规则，IDE可能是错误的，但是总是（？）告诉我们正在做什么的真相）。

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

    
    
    • 在这种情况下，为什么堆栈跟踪实际上在堆栈跟踪中的方法的签名？
      
      
      
      
      • 这是由于编译器？运行时？还有什么？
      
      

      推荐答案

      这通常与缺少调试信息有关。您可能正在使用JRE（不是JDK），它不包括rt.jar类的调试信息。尝试使用完整的JDK，您将在堆栈跟踪中获取正确的位置：

      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)
      

      这篇关于（未知来源）在异常堆栈跟踪的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！