Rob*_*ska 622 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)
Run Code Online (Sandbox Code Playgroud)
人们将此称为"堆栈跟踪".什么是堆栈跟踪?有什么能告诉我程序中发生的错误?
关于这个问题 - 我经常看到一个问题,一个新手程序员"得到一个错误",他们只是粘贴他们的堆栈跟踪和一些随机的代码块,而不了解堆栈跟踪是什么或如何使用它.这个问题旨在作为新手程序员的参考,他们可能需要帮助来理解堆栈跟踪的价值.
Rob*_*ska 570
简单来说,堆栈跟踪是应用程序在抛出异常时处于中间的方法调用的列表.
简单的例子
通过问题中给出的示例,我们可以确切地确定应用程序中抛出异常的位置.我们来看看堆栈跟踪:
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)
Run Code Online (Sandbox Code Playgroud)
这是一个非常简单的堆栈跟踪.如果我们从"at ..."列表的开头开始,我们可以告诉我们的错误发生在哪里.我们正在寻找的是作为我们应用程序一部分的最顶层方法调用.在这种情况下,它是:
at com.example.myproject.Book.getTitle(Book.java:16)
Run Code Online (Sandbox Code Playgroud)
为了调试这个,我们可以打开Book.java
并查看一行16
,即:
15 public String getTitle() {
16 System.out.println(title.toString());
17 return title;
18 }
Run Code Online (Sandbox Code Playgroud)
这表明上述代码中存在某些内容(可能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 }
Run Code Online (Sandbox Code Playgroud)
这可能会为您提供如下所示的堆栈跟踪:
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
Run Code Online (Sandbox Code Playgroud)
这个有什么不同的是"引起的".有时,异常会有多个"由...引起"部分.对于这些,您通常希望找到"根本原因",它将是堆栈跟踪中最低的"由...引起"部分之一.在我们的例子中,它是:
Caused by: java.lang.NullPointerException <-- root cause
at com.example.myproject.Book.getId(Book.java:22) <-- important line
Run Code Online (Sandbox Code Playgroud)
同样,对于此例外,我们会想看看行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
Run Code Online (Sandbox Code Playgroud)
在这个例子中,还有更多.我们最关心的是寻找来自我们代码的方法,这些方法可以是com.example.myproject
包中的任何内容.从第二个例子(上图)开始,我们首先要查看根本原因,即:
Caused by: java.sql.SQLException
Run Code Online (Sandbox Code Playgroud)
但是,其下的所有方法调用都是库代码.所以我们将向上移动到它上面的"由...引起",并寻找源自我们代码的第一个方法调用,即:
at com.example.myproject.MyEntityService.save(MyEntityService.java:59)
Run Code Online (Sandbox Code Playgroud)
就像在前面的例子中,我们应该看看MyEntityService.java
就行59
,因为这是此错误的起源(这个有点明显出了什么问题,因为SQLException中发生的错误,但调试程序是什么我们之后).
Dak*_*ron 74
我发布这个答案所以最顶层的答案(按活动排序)不是一个完全错误的答案.
什么是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.
Run Code Online (Sandbox Code Playgroud)
我该如何处理Stacktraces/Exceptions?
首先,找出导致异常的原因.尝试googleing异常的名称以找出,该异常的原因是什么.大多数情况下,它将由错误的代码引起.在上面给出的示例中,所有异常都是由不正确的代码引起的.因此,对于NullPointerException示例,您可以确保a
此时从不为null.例如,您可以初始化a
或包含类似以下的支票:
if (a!=null) {
a.toString();
}
Run Code Online (Sandbox Code Playgroud)
这样,如果是,则不执行违规行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!")
}
Run Code Online (Sandbox Code Playgroud)
我为什么不用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;
}
}
Run Code Online (Sandbox Code Playgroud)
这段代码是试图做的是赶上ArithmeticException
由0引起的可能的分裂,但它还捕捉可能的NullPointerException
,如果被抛出a
或者b
是null
.这意味着,你可能得到一个,NullPointerException
但你会把它当作ArithmeticException,可能做错了.在最好的情况下,你仍然会错过NullPointerException.这样的东西使得调试变得更加困难,所以不要这样做.
TLDR
如果1.不可能,请捕获特定的异常并处理它.
catch (Exception e)
,始终捕获特定的例外.这将为您节省很多麻烦.Woo*_*Moo 21
添加Rob提到的内容.在应用程序中设置断点允许逐步处理堆栈.这使开发人员能够使用调试器来查看该方法在何种情况下执行的操作是意料之外的事情.
由于Rob使用NullPointerException
(NPE)来说明常见的东西,我们可以通过以下方式帮助解决此问题:
如果我们有一个方法,采取如下参数: void (String firstName)
在我们的代码中,我们想要评估firstName
包含值,我们会这样做:if(firstName == null || firstName.equals("")) return;
以上内容阻止我们将其firstName
用作不安全的参数.因此,通过在处理之前进行空检查,我们可以帮助确保我们的代码能够正常运行.要扩展使用带有方法的对象的示例,我们可以在这里查看:
if(dog == null || dog.firstName == null) return;
以上是检查空值的正确顺序,我们从基础对象开始,在这种情况下是狗,然后开始走下可能性树,以确保在处理之前一切都是有效的.如果订单被撤销,NPE可能会被抛出,我们的程序会崩溃.
prz*_*tel 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();
}
}
Run Code Online (Sandbox Code Playgroud)
堆栈跟踪:
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)
Run Code Online (Sandbox Code Playgroud)
操纵堆栈跟踪:
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();
}
}
Run Code Online (Sandbox Code Playgroud)
堆栈跟踪:
Exception in thread "main" java.lang.RuntimeException
at OtherClass.methodX(String.java:99)
at OtherClass.methodY(String.java:55)
Run Code Online (Sandbox Code Playgroud)
小智 15
要理解名称:堆栈跟踪是一个异常列表(或者你可以说是"原因"列表),从最表面的异常(例如服务层异常)到最深的异常(例如数据库异常).就像我们称之为'堆栈'的原因是因为堆栈是先进先出(FILO),最深的异常发生在最开始,然后一串异常产生了一系列后果,表面异常是最后一个一个发生在时间上,但我们首先看到它.
关键1:需要理解的一个棘手而重要的事情是:最深层的原因可能不是"根本原因",因为如果你写了一些"坏代码",它可能会导致一些比它的层更深的例外.例如,错误的SQL查询可能导致在bottem中重置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)
Run Code Online (Sandbox Code Playgroud)
Book.java:16由Auther.java:25调用,由Bootstrap.java调用:14,Book.java:16是根本原因.这里附上一个图表按时间顺序对跟踪堆栈进行排序.
只是为了添加到其他示例,内部(嵌套)类与$
符号一起出现.例如:
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();
}
}
Run Code Online (Sandbox Code Playgroud)
将导致此堆栈跟踪:
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)
Run Code Online (Sandbox Code Playgroud)
其他帖子描述了堆栈跟踪的内容,但仍然很难处理.
如果您获得了堆栈跟踪并希望跟踪异常的原因,那么理解它的一个很好的起点是在Eclipse中使用Java堆栈跟踪控制台.如果你使用另一个IDE,可能会有类似的功能,但这个答案是关于Eclipse的.
首先,确保您在Eclipse项目中可以访问所有Java源代码.
然后在Java透视图中,单击Console选项卡(通常在底部).如果看不到Console视图,请转到菜单选项Window - > Show View并选择Console.
然后在控制台窗口中,单击以下按钮(在右侧)
然后从下拉列表中选择Java Stack Trace Console.
将堆栈跟踪粘贴到控制台中.然后,它将提供源代码和任何其他可用源代码的链接列表.
这是您可能会看到的(Eclipse文档中的图像):
由最近的方法调用将是顶部堆叠的,这是顶线(不包括消息文本).走下堆栈可以追溯到时间.第二行是调用第一行的方法,等等.
如果您使用的是开源软件,则可能需要下载并将项目附加到项目中(如果要检查).下载源jar,在项目中打开Referenced Libraries文件夹,找到开源模块的jar(带有类文件的jar ),然后右键单击,选择Properties并附加源jar.