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

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

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)

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

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

565491 次浏览
小开
最佳答案

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

简单示例

通过问题中给出的示例，我们可以准确确定异常在应用程序中的引发位置。让我们看看堆栈跟踪：

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

同样，除了这个例外，我们想看看Book.java的22行，看看是什么可能导致这里的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

但是，它下的所有方法调用都是库代码。因此，我们将向上移动转到上面的“造成” it，并在“由”块中查找源自我们代码的第一个方法调用，即：

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

与前面的示例一样，我们应该查看59行上的MyEntityService.java，因为这是此错误的起源（这个错误有点明显，因为SQLException声明了错误，但调试过程是我们所追求的）。

小开

添加到罗伯提到的内容。在您的应用程序中设置断点允许对堆栈进行分步处理。这使开发人员能够使用调试器来查看该方法在哪个确切点正在做一些意料之外的事情。

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

如果我们有一个方法接受以下参数：void (String firstName)

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

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

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

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

小开

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)
小开

其他文章描述了堆栈跟踪是什么，但它仍然很难使用。

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

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

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

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

控制台按钮

然后从下拉列表中选择Java堆栈跟踪控制台。

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

例如，如果我们有这个程序：

public class ExceptionTest {
    

public static void main(String[] args) {
int l = trimmedLength(null);
System.out.println("Trimmed length = " + l);
}
    

private static int trimmedLength(String string) {
return string.trim().length();
}
}

你会得到这个堆栈跟踪：

粘贴的堆栈跟踪

最近进行的方法调用（也是导致异常的方法调用）将是堆栈的顶部，它是顶行（不包括错误消息文本）。在这种情况下，那就是trimmedLength方法。向下堆栈返回时间。第二行是调用第一行的方法，依此类推。

如果您使用的是开源软件，如果您想检查，您可能需要下载源代码并将其附加到您的项目中。下载源代码jar，在您的项目中，打开参考图书馆文件夹以找到您的开源模块的jar（包含类文件的那个），然后右键单击，选择属性并附加源代码jar。

小开

什么是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.

我应该如何处理堆栈跟踪/异常？

首先，找出导致异常的原因。尝试谷歌搜索异常的名称以找出该异常的原因是什么。大多数情况下，它将由不正确的代码引起。在上面给出的示例中，所有的异常都是由不正确的代码引起的。因此，对于NullPointerException示例，你可以确保a当时永远不会为空。例如，你可以初始化a或包含像这样的检查：

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

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

有时你无法确保没有异常。例如，如果你在程序中使用网络连接，你无法阻止计算机失去它的互联网连接（例如，你无法阻止用户断开计算机的网络连接）。在这种情况下，网络库可能会抛出异常。现在你应该捕获异常并处理它。这意味着，在网络连接的例子中，你应该尝试重新打开连接或通知用户或类似的事情。此外，每当你使用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;
}
}

这段代码试图做的是捕获由可能的除0引起的ArithmeticException。但它也捕获如果a或b是null则抛出的可能的NullPointerException。这意味着，你可能会得到一个NullPointerException，但你会将其视为ArithmeticException，并且可能会做错事情。在最好的情况下，你仍然错过了NullPointerException。这样的东西会使调试更加困难，所以不要这样做。

TLDR

  1. 找出异常的原因并修复它，以便它根本不会抛出异常。
  2. 如果1.不可能，捕获特定的异常并处理它。
    • 永远不要只是添加一个try/catch，然后忽略异常！不要这样做！
    • 永远不要使用catch (Exception e)，总是捕获特定的异常。这将为您节省很多麻烦。
小开

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

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)
小开

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

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

->找到中间的根本原因是你的工作。 输入图片描述

键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:25Bootstrap.java:14称为，Book.java:16是根本原因。 这里附上一个图表，按时间顺序对跟踪堆栈进行排序。 输入图片描述


提交答案