什么是堆栈跟踪,如何使用它调试应用程序错误?

wvt8vs2t  于 2021-10-10  发布在  Java
关注(0)|答案(7)|浏览(281)

有时,当我运行应用程序时,会出现如下错误:

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)

人们称之为“堆栈跟踪”。什么是堆栈跟踪?它能告诉我程序中发生的错误吗?
关于这个问题——我经常看到一个问题,一个新手程序员“遇到了错误”,他们只是简单地粘贴他们的堆栈跟踪和一些随机代码块,而不了解堆栈跟踪是什么或如何使用它。这个问题旨在为新手程序员提供参考,他们可能需要帮助理解堆栈跟踪的价值。

im9ewurl

im9ewurl1#

简单地说,堆栈跟踪是应用程序处于异常抛出时的方法调用的列表。
简单例子
通过问题中给出的示例,我们可以准确地确定在应用程序中引发异常的位置。让我们看看堆栈跟踪:

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声明了错误,但调试过程是我们要做的)。

oyt4ldly

oyt4ldly2#

什么是堆栈跟踪?
stacktrace是一个非常有用的调试工具。它显示了抛出未捕获异常时(或手动生成stacktrace时)的调用堆栈(即调用到该点的函数堆栈)。这是非常有用的,因为它不仅显示了错误发生的位置,而且还显示了程序如何在代码所在的位置结束。这就引出了下一个问题:
什么是例外?
异常是运行时环境用来告诉您发生错误的情况。常见的例子有nullpointerexception、indexoutofboundsexception或算术异常。这些都是当你试图做一些不可能的事情时引起的。例如,当您尝试取消引用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 . 其他例子也是如此。
有时你不能确保你没有得到一个例外。例如,如果您在程序中使用网络连接,则无法阻止计算机断开其internet连接(例如,您无法阻止用户断开计算机的网络连接)。在这种情况下,网络库可能会抛出异常。现在您应该捕获异常并处理它。这意味着,在网络连接的示例中,您应该尝试重新打开连接或通知用户或类似的事情。另外,无论何时使用catch,总是只捕获要捕获的异常,不要使用像这样的泛泛catch语句 catch (Exception e) 这将涵盖所有例外情况。这一点非常重要,因为否则您可能会意外捕获错误的异常并以错误的方式做出React。

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 如果 abnull . 这意味着,你可能会得到一个 NullPointerException 但你会把它当作算术上的例外,可能会做错事。在最好的情况下,您仍然忽略了nullpointerexception。这样的事情会使调试变得更加困难,所以不要这样做。
太长,读不下去了
找出异常的原因并修复它,这样它就不会抛出异常。
如果1.不可能,则捕获特定异常并处理它。
永远不要只添加一个try/catch,然后忽略异常!不要那样做!
从不使用 catch (Exception e) ,始终捕获特定的异常。那会帮你省去很多麻烦。

sqxo8psd

sqxo8psd3#

补充rob提到的内容。在应用程序中设置断点可以逐步处理堆栈。这使开发人员能够使用调试器来查看该方法在什么确切的点上正在做一些出乎意料的事情。
自从rob使用了 NullPointerException (npe)为了说明一些常见问题,我们可以通过以下方式帮助解决此问题:
如果我们有一个采用如下参数的方法: void (String firstName) 在我们的代码中,我们希望对此进行评估 firstName 包含一个值,我们将这样做: if(firstName == null || firstName.equals("")) return; 上述情况阻止我们使用 firstName 作为一个不安全的参数。因此,通过在处理之前进行空检查,我们可以帮助确保代码正常运行。要扩展使用对象和方法的示例,我们可以查看以下内容: if(dog == null || dog.firstName == null) return; 以上是检查空值的正确顺序,我们从基本对象开始,在本例中是dog,然后开始沿着可能性树向下走,以确保在处理之前所有内容都有效。如果顺序颠倒,npe可能被抛出,我们的程序将崩溃。

fiei3ece

fiei3ece4#

理解名称:堆栈跟踪是一个异常列表(或者你可以说是一个“原因”列表),从最表面的异常(例如服务层异常)到最深层的异常(例如数据库异常)。正如我们称之为“堆栈”的原因是因为堆栈是先进先出(filo),最深的异常在一开始就发生了,然后一系列异常产生了一系列后果,表面异常是最后一个及时发生的异常,但我们首先看到了它。
关键1:这里需要理解的一件棘手而重要的事情是:最深层的原因可能不是“根本原因”,因为如果你写了一些“坏代码”,它可能会导致一些比它的层次更深的异常。例如,一个坏的SQL查询可能会导致BoTTEM中SQLServer异常连接复位,而不是SyDaX错误,这可能正好在堆栈的中间。
在中间找到根本原因是你的工作。

关键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)

bootstrap调用的auther.java:25调用了book.java:16。java:14,book.java:16是根本原因。这里附上一个图表,按时间顺序对跟踪堆栈进行排序。

uqxowvwt

uqxowvwt5#

throwable系列还提供了一个stacktrace功能,即可以操作堆栈跟踪信息。
标准行为:

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)
0yg35tkg

0yg35tkg6#

为了添加到其他示例中,有一些内部(嵌套)类与 $ 签名例如:

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

eqzww0vc7#

其他帖子描述了堆栈跟踪是什么,但它仍然很难使用。
如果您得到一个堆栈跟踪,并希望跟踪异常的原因,那么了解它的一个好的起点是在eclipse中使用java堆栈跟踪控制台。如果您使用另一个ide,可能会有类似的特性,但这个答案是关于eclipse的。
首先,确保在eclipse项目中可以访问所有java源代码。
然后在java透视图中,单击console选项卡(通常在底部)。如果控制台视图不可见,请转到菜单选项窗口->显示视图并选择控制台。
然后在控制台窗口中,单击以下按钮(右侧)

然后从下拉列表中选择java堆栈跟踪控制台。
将堆栈跟踪粘贴到控制台中。然后,它将提供一个链接列表,链接到您的源代码和任何其他可用的源代码中。
这是您可能看到的(eclipse文档中的图像):

这个

相关问题