有时,当我运行我的应用程序时,它给我一个错误,看起来像:
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)
人们将其称为“堆栈跟踪”。什么是堆栈跟踪?关于程序中发生的错误,它能告诉我什么?
关于这个问题-我经常看到一个问题,这个问题是新手程序员“遇到错误”的地方,他们只是粘贴了堆栈跟踪和一些随机的代码块,却不了解堆栈跟踪是什么或如何使用它。该问题旨在为可能需要帮助来了解堆栈跟踪值的新手程序员提供参考。
简而言之,堆栈跟踪是在抛出Exception时应用程序处于中间的方法调用的列表。
简单的例子
使用问题中给出的示例,我们可以准确确定在应用程序中引发异常的位置。让我们看一下堆栈跟踪:
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并查看line 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”不同。有时,例外会有多个“由…引起”部分。对于这些,您通常希望找到“根本原因”,这将是堆栈跟踪中最低的“ Cause by”部分之一。在我们的例子中是:
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
但是,该方法下的所有方法调用都是库代码。因此,我们将向上移至其上方的“ Caused by”,并寻找源于我们代码的第一个方法调用,即:
at com.example.myproject.MyEntityService.save(MyEntityService.java:59)
就像在前面的例子中,我们应该看看MyEntityService.java
就行59,因为这是此错误的起源(这个有点明显出了什么问题,因为SQLException中发生的错误,但调试程序是什么,我们以后是)。
前言我改了标题。很难理解为什么在调试时,有时未被捕获的异常会向Logcat输出“致命异常”,而有时不会。 下面的简化示例在我到达 line 时崩溃了。Logcat 内部没有堆栈跟踪或其他指示,说明出了什么问题。我运行的是 Android Studio 3.0.0beta4。 为什么它会崩溃?(更新-崩溃是由于安全例外) 为什么Logcat不显示堆栈跟踪或其他错误 更新好了,我知道它为什么崩溃了。我
我使用以下代码打印try-catch块中发生的任何异常,但是当异常发生时,logback不会打印完整的堆栈跟踪,而是写入一行错误(它没有明确说明是什么导致了它。我如何在logback输出中打印完整的堆栈跟踪? 尝试捕获异常的catch块 日志返回错误输出:
问题内容: 程序中没有单个方法“知道”它在堆栈中的位置。它所知道的只是它自己的小工作,它完成了并返回了。因此,当引发异常并打印堆栈跟踪时,它是从哪里来的? 在JVM中监视程序状态的每个应用程序旁边隐式地运行着一个单独的线程吗?还是JVM本身保存此信息,并且在抛出异常时以某种方式从异常中提取数据? 如果是上述两种情况之一,是否可以使用某些调用来检索堆栈跟踪(从监视器线程或JVM) 而不会 引发异常?
当Xdebug被激活时,只要PHP决定显示通知,警告,错误等,就会显示堆栈跟踪。堆栈跟踪显示的信息以及显示方式可以根据您的需要进行配置。 Xdebug在错误情况下显示的堆栈跟踪信息量相当保守(如果display.errors 在php.ini中设置为On)。这是因为大量的信息会减慢脚本的执行速度和浏览器中堆栈跟踪本身的渲染速度。但是,可以使堆栈轨迹以不同的设置显示更详细的信息。 堆栈跟踪中的变量
问题内容: 当您在Java中使用RMI时,收到异常时将在其前面添加远程堆栈跟踪,如下所示: 那种堆栈跟踪“伪造”如何完成? 我想要什么(除了被迭代)?好吧,如果我能这样做的话,它将对我有帮助: 并使其成为引发日志记录的目的,在堆栈跟踪中也将引发异常(并且方法在链的下游)。 问题答案: 这很容易: Throwable有方法和。 从我的一个项目(非开源,但也许有一天我将打开远程调用引擎): 为了您的方
问题内容: 我最近发现了一个导致NullPointerException的错误。使用标准slf4j语句捕获并记录该异常。下面的节略代码: 如您所见,没有任何幻想。但是,在我们拥有的所有异常日志记录语句中,仅此一条不会打印堆栈跟踪。它仅打印消息(表示为“ …”)和异常类的名称(java.lang.NullPointerException)。 由于对异常的堆栈跟踪是延迟加载的,因此我认为可能存在某种指