什么是堆栈跟踪，如何使用它来调试应用程序错误？

时间：2010-10-21 14:52:25

标签： java debugging stack-trace

有时当我运行我的应用程序时，它会给我一个看起来像的错误：

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(Book.java:16)
        at com.example.myproject.Author.getBookTitles(Author.java:25)
        at com.example.myproject.Bootstrap.main(Bootstrap.java:14)

人们将此称为“堆栈跟踪”。 什么是堆栈跟踪？有什么能告诉我程序中发生的错误？

关于这个问题 - 我经常看到一个新手程序员“得到错误”的问题，他们只是粘贴他们的堆栈跟踪和一些随机代码块而不了解堆栈跟踪是什么或者他们如何使用它。这个问题旨在作为新手程序员的参考，他们可能需要帮助来理解堆栈跟踪的价值。

7 个答案:

答案 0 :(得分：536)

简单来说，堆栈跟踪是应用程序在抛出异常时处于中间的方法调用的列表。

简单示例

通过问题中给出的示例，我们可以确切地确定应用程序中抛出异常的位置。我们来看看堆栈跟踪：

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(Book.java:16)
        at com.example.myproject.Author.getBookTitles(Author.java:25)
        at com.example.myproject.Bootstrap.main(Bootstrap.java:14)

这是一个非常简单的堆栈跟踪。如果我们从“at ...”列表的开头开始，我们可以告诉我们的错误发生在哪里。我们正在寻找的是最顶层的方法调用，它是我们应用程序的一部分。在这种情况下，它是：

at com.example.myproject.Book.getTitle(Book.java:16)

要对此进行调试，我们可以打开Book.java并查看第16行，即：

15   public String getTitle() {
16      System.out.println(title.toString());
17      return title;
18   }

这表明上述代码中的某些内容（可能title）为null。

带有例外链的示例

有时应用程序会捕获异常并将其作为另一个异常的原因重新抛出。这通常看起来像：

34   public void getBookIds(int id) {
35      try {
36         book.getId(id);    // this method it throws a NullPointerException on line 22
37      } catch (NullPointerException e) {
38         throw new IllegalStateException("A book has a null property", e)
39      }
40   }

这可能会为您提供如下所示的堆栈跟踪：

Exception in thread "main" java.lang.IllegalStateException: A book has a null property
        at com.example.myproject.Author.getBookIds(Author.java:38)
        at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
Caused by: java.lang.NullPointerException
        at com.example.myproject.Book.getId(Book.java:22)
        at com.example.myproject.Author.getBookIds(Author.java:36)
        ... 1 more

这个问题的不同之处在于“引起的”。有时，异常会有多个“由...引起”部分。对于这些，您通常希望找到“根本原因”，它将是堆栈跟踪中最低的“由...引起”部分之一。在我们的例子中，它是：

Caused by: java.lang.NullPointerException <-- root cause
        at com.example.myproject.Book.getId(Book.java:22) <-- important line

同样，有了这个例外，我们想查看22的第Book.java行，看看这里可能会导致NullPointerException的内容。

图书馆代码更令人生畏的例子

通常堆栈跟踪比上面两个例子复杂得多。这是一个例子（它是一个很长的例子，但展示了几个级别的链式异常）：

javax.servlet.ServletException: Something bad happened
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:60)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.ExceptionHandlerFilter.doFilter(ExceptionHandlerFilter.java:28)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at com.example.myproject.OutputBufferFilter.doFilter(OutputBufferFilter.java:33)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
    at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
    at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
    at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
    at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
    at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
    at org.mortbay.jetty.Server.handle(Server.java:326)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
    at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
    at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: com.example.myproject.MyProjectServletException
    at com.example.myproject.MyServlet.doPost(MyServlet.java:169)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
    at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
    at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
    at com.example.myproject.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:30)
    ... 27 more
Caused by: org.hibernate.exception.ConstraintViolationException: could not insert: [com.example.myproject.MyEntity]
    at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96)
    at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
    at org.hibernate.id.insert.AbstractSelectingDelegate.performInsert(AbstractSelectingDelegate.java:64)
    at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2329)
    at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2822)
    at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:71)
    at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:268)
    at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:321)
    at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
    at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:130)
    at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:210)
    at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:56)
    at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:195)
    at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:50)
    at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93)
    at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:705)
    at org.hibernate.impl.SessionImpl.save(SessionImpl.java:693)
    at org.hibernate.impl.SessionImpl.save(SessionImpl.java:689)
    at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:344)
    at $Proxy19.save(Unknown Source)
    at com.example.myproject.MyEntityService.save(MyEntityService.java:59) <-- relevant call (see notes below)
    at com.example.myproject.MyServlet.doPost(MyServlet.java:164)
    ... 32 more
Caused by: java.sql.SQLException: Violation of unique constraint MY_ENTITY_UK_1: duplicate value(s) for column(s) MY_COLUMN in statement [...]
    at org.hsqldb.jdbc.Util.throwError(Unknown Source)
    at org.hsqldb.jdbc.jdbcPreparedStatement.executeUpdate(Unknown Source)
    at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:105)
    at org.hibernate.id.insert.AbstractSelectingDelegate.performInsert(AbstractSelectingDelegate.java:57)
    ... 54 more

在这个例子中，还有更多。我们最关心的是寻找来自我们的代码的方法，这些方法可以是com.example.myproject包中的任何内容。从第二个例子（上图）开始，我们首先要查看根本原因，即：

Caused by: java.sql.SQLException

但是，其下的所有方法调用都是库代码。所以我们将向上移动到它上面的“由...引起”，并寻找源自我们代码的第一个方法调用，即：

at com.example.myproject.MyEntityService.save(MyEntityService.java:59)

与之前的示例一样，我们应该查看MyEntityService.java行59，因为这是错误发生的地方（这个有点明显出错了，因为SQLException表示错误，但是调试程序就是我们追求的目标。

答案 1 :(得分：72)

我发布这个答案，所以最重要的答案（按活动排序）不是一个完全错误的答案。

什么是Stacktrace？

stacktrace是一个非常有用的调试工具。它显示了在抛出未捕获的异常时（或手动生成堆栈跟踪的时间）的调用堆栈（意味着，被调用到该点的函数堆栈）。这非常有用，因为它不仅可以显示错误发生的位置，还可以显示程序在代码所在位置的结果。 这导致了下一个问题：

什么是例外？

异常是运行时环境用来告诉您发生错误的内容。流行的例子是NullPointerException，IndexOutOfBoundsException或ArithmeticException。当您尝试执行不可能的操作时，会导致其中的每一个。例如，当您尝试取消引用Null对象时，将抛出NullPointerException：

Object a = null;
a.toString();                 //this line throws a NullPointerException

Object[] b = new Object[5];
System.out.println(b[10]);    //this line throws an IndexOutOfBoundsException,
                              //because b is only 5 elements long
int ia = 5;
int ib = 0;
ia = ia/ib;                   //this line throws an  ArithmeticException with the 
                              //message "/ by 0", because you are trying to
                              //divide by 0, which is not possible.

我应该如何处理Stacktraces / Exceptions？

首先，找出造成异常的原因。尝试googleing异常的名称以找出，该异常的原因是什么。大多数情况下，它将由错误的代码引起。在上面给出的示例中，所有异常都是由不正确的代码引起的。因此，对于NullPointerException示例，您可以确保当时a永远不为null。例如，您可以初始化a或包含类似这样的支票：

if (a!=null) {
    a.toString();
}

这样，如果a==null，则不执行违规行。其他例子也是如此。

有时你不能确保你没有得到例外。例如，如果您在程序中使用网络连接，则无法阻止计算机丢失其Internet连接（例如，您无法阻止用户断开计算机的网络连接）。在这种情况下，网络库可能会抛出异常。现在您应该捕获异常并处理它。这意味着，在具有网络连接的示例中，您应该尝试重新打开连接或通知用户或类似的东西。此外，无论何时使用catch，总是只捕获要捕获的异常，不要使用可捕获所有异常的广泛catch语句，如catch (Exception e) 。这非常重要，否则您可能会意外地捕获错误的异常并以错误的方式做出反应。

try {
    Socket x = new Socket("1.1.1.1", 6789);
    x.getInputStream().read()
} catch (IOException e) {
    System.err.println("Connection could not be established, please try again later!")
}

我为什么不使用catch (Exception e)？

让我们用一个小例子来说明为什么你不应该只捕获所有例外：

int mult(Integer a,Integer b) {
    try {
        int result = a/b
        return result;
    } catch (Exception e) {
        System.err.println("Error: Division by zero!");
        return 0;
    }
}

此代码尝试执行的操作是捕获由可能除法引起的ArithmeticException 0.但它还会捕获NullPointerException或{{a时可能引发的b 1}}是null。这意味着，您可能会获得NullPointerException，但您会将其视为ArithmeticException并且可能做错了。在最好的情况下，你仍然会错过NullPointerException。这样的东西使得调试变得更加困难，所以不要这样做。

<强> TLDR

  1. 找出异常的原因并修复它，以便它不会抛出异常。

  2. 如果无法执行1.，请捕获特定异常并进行处理。

    • 永远不要只添加一个try / catch然后忽略异常！不要那样做！
    • 永远不要使用catch (Exception e)，始终捕获特定的例外情况。这样可以省去很多麻烦。

答案 2 :(得分：21)

补充Rob提到的内容。在应用程序中设置断点允许逐步处理堆栈。这使开发人员可以使用调试器来查看该方法在哪些方面正在做一些意料之外的事情。

由于Rob使用NullPointerException（NPE）来说明常见问题，我们可以通过以下方式帮助解决此问题：

如果我们的方法采用如下参数：void (String firstName)

在我们的代码中，我们要评估firstName是否包含值，我们会这样做：if(firstName == null || firstName.equals("")) return;

以上内容阻止我们将firstName用作不安全的参数。因此，通过在处理之前进行空检查，我们可以帮助确保我们的代码能够正常运行。要扩展使用方法的对象的示例，我们可以在这里查看：

if(dog == null || dog.firstName == null) return;

以上是检查空值的正确顺序，我们从基础对象开始，在这种情况下是狗，然后开始走下可能性树，以确保在处理之前一切都是有效的。如果订单被撤销，NPE可能会被抛出，我们的程序会崩溃。

答案 3 :(得分：15)

Throwable系列还提供了一个堆栈跟踪功能 - 可以操作堆栈跟踪信息。

标准行为： 

package test.stack.trace;

public class SomeClass {

    public void methodA() {
        methodB();
    }

    public void methodB() {
        methodC();
    }

    public void methodC() {
        throw new RuntimeException();
    }

    public static void main(String[] args) {
        new SomeClass().methodA();
    }
}

堆栈追踪：

Exception in thread "main" java.lang.RuntimeException
    at test.stack.trace.SomeClass.methodC(SomeClass.java:18)
    at test.stack.trace.SomeClass.methodB(SomeClass.java:13)
    at test.stack.trace.SomeClass.methodA(SomeClass.java:9)
    at test.stack.trace.SomeClass.main(SomeClass.java:27)

操纵堆栈跟踪： 

package test.stack.trace;

public class SomeClass {

    ...

    public void methodC() {
        RuntimeException e = new RuntimeException();
        e.setStackTrace(new StackTraceElement[]{
                new StackTraceElement("OtherClass", "methodX", "String.java", 99),
                new StackTraceElement("OtherClass", "methodY", "String.java", 55)
        });
        throw e;
    }

    public static void main(String[] args) {
        new SomeClass().methodA();
    }
}

堆栈追踪：

Exception in thread "main" java.lang.RuntimeException
    at OtherClass.methodX(String.java:99)
    at OtherClass.methodY(String.java:55)

答案 4 :(得分：14)

要理解名称：堆栈跟踪是一个例外列表（或者你可以说是“原因”列表），从最表面的异常（例如服务层异常）到最深的一个（例如数据库异常）。就像我们称之为'堆栈'的原因是因为堆栈是先进先出（FILO），最深的异常发生在最开始，然后一系列异常产生了一系列后果，表面异常是最后一个一个发生在时间上，但我们首先看到它。

Key 1 ：这里需要理解的一个棘手而重要的事情是：最深层的原因可能不是“根本原因”，因为如果你写了一些“坏代码”，它可能会导致下面的一些例外比它的层更深。例如，错误的SQL查询可能导致在bottem中重置SQLServerException连接而不是syndax错误，这可能只是在堆栈的中间。

- ＆GT; 找到中间的根本原因是你的工作。 enter image description here

键2 ：另一个棘手但重要的事情是在每个“原因”块中，第一行是最深层，并且发生在此块的第一位。例如，

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(Book.java:16)
           at com.example.myproject.Author.getBookTitles(Author.java:25)
               at com.example.myproject.Bootstrap.main(Bootstrap.java:14)

Book.java:16由Auther.java:25调用，由Bootstrap.java调用：14，Book.java：16是根本原因。 这里附上一个图表按时间顺序对跟踪堆栈进行排序。 enter image description here

答案 5 :(得分：8)

只是添加到其他示例中，内部（嵌套）类与$符号一起显示。例如：

public class Test {

    private static void privateMethod() {
        throw new RuntimeException();
    }

    public static void main(String[] args) throws Exception {
        Runnable runnable = new Runnable() {
            @Override public void run() {
                privateMethod();
            }
        };
        runnable.run();
    }
}

将导致此堆栈跟踪：

Exception in thread "main" java.lang.RuntimeException
        at Test.privateMethod(Test.java:4)
        at Test.access$000(Test.java:1)
        at Test$1.run(Test.java:10)
        at Test.main(Test.java:13)

答案 6 :(得分：5)

其他帖子描述了堆栈跟踪的内容，但仍然难以使用。

如果您获得堆栈跟踪并想要跟踪异常的原因，理解它的一个良好的起点是在 Eclipse 中使用 Java堆栈跟踪控制台 。如果你使用另一个IDE，可能会有类似的功能，但这个答案是关于Eclipse的。

首先，确保您在Eclipse项目中可以访问所有Java源。

然后在 Java 透视图中，单击控制台选项卡（通常位于底部）。如果看不到控制台视图，请转到菜单选项窗口 - ＆gt;显示视图并选择控制台。

然后在控制台窗口中，单击以下按钮（右侧）

Consoles button

然后从下拉列表中选择 Java Stack Trace Console 。

将堆栈跟踪粘贴到控制台中。然后，它将提供源代码和任何其他可用源代码的链接列表。

您可能会看到这些内容（Eclipse文档中的图片）：

Diagram from Eclipse documentation

最近进行的方法调用将是堆栈的 top ，它是顶行（不包括消息文本）。走下堆栈可以追溯到时间。第二行是调用第一行等的方法

如果您使用的是开源软件，则可能需要下载并将项目附加到项目中（如果要检查）。在项目中下载源jar，打开 Referenced Libraries 文件夹，找到开源模块的jar（带有类文件的jar），然后右键单击，选择 Properties 并附上源jar。

相关问题
最新问题