异常堆栈跟踪中的(未知来源)

(Unknown Source) in Exception stack trace(异常堆栈跟踪中的(未知来源))

问题描述

这个问题与 为什么String有关.valueOf(null) 抛出 NullPointerException?

考虑以下代码段:

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 的方法重载将上述调用解析为 String.valueOf(char[])，这会导致 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)

请注意，上面的堆栈跟踪缺少 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.

目前，我可以看到程序员可以通过上述代码段识别问题的 3 种方法:

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)
      

      这篇关于异常堆栈跟踪中的(未知来源)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！