¿Qué es un seguimiento de pila y cómo puedo usarlo para depurar los errores de mi aplicación?
A veces, cuando ejecuto mi aplicación, me da un error que se parece a:
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)
La gente se ha referido a esto como un "seguimiento de pila". ¿Qué es un seguimiento de pila? ¿Qué me puede decir sobre el error que está ocurriendo en mi programa?
Acerca de esta pregunta: muy a menudo veo una pregunta en la que un programador novato está "obteniendo un error", y simplemente pegan su seguimiento de pila y algún bloque de código aleatorio sin entender qué es el seguimiento de pila o cómo pueden usarlo. Esta pregunta está destinada a ser una referencia para los programadores novatos que puedan necesitar ayuda para comprender el valor de un seguimiento de pila.
Respuestas
En términos simples, un seguimiento de pila es una lista de las llamadas al método en las que la aplicación estaba en el medio cuando se lanzó una excepción.
Ejemplo simple
Con el ejemplo dado en la pregunta, podemos determinar exactamente dónde se lanzó la excepción en la aplicación. Echemos un vistazo al seguimiento de la pila:
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)
Este es un seguimiento de pila muy simple. Si comenzamos al principio de la lista de "en ...", podemos decir dónde ocurrió nuestro error. Lo que estamos buscando es la llamada al método superior que forma parte de nuestra aplicación. En este caso, es:
at com.example.myproject.Book.getTitle(Book.java:16)
Para depurar esto, podemos abrir Book.javay mirar la línea 16, que es:
15 public String getTitle() {
16 System.out.println(title.toString());
17 return title;
18 }
Esto indicaría que algo (probablemente title) está nullen el código anterior.
Ejemplo con una cadena de excepciones
A veces, las aplicaciones detectan una excepción y la vuelven a lanzar como la causa de otra excepción. Esto normalmente se ve así:
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 }
Esto podría darle un seguimiento de la pila que se parece a:
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
Lo que es diferente de este es el "Causado por". A veces, las excepciones tendrán varias secciones "Causado por". Para estos, normalmente desea encontrar la "causa raíz", que será una de las secciones más bajas de "Causado por" en el seguimiento de la pila. En nuestro caso, es:
Caused by: java.lang.NullPointerException <-- root cause
at com.example.myproject.Book.getId(Book.java:22) <-- important line
Nuevamente, con esta excepción, nos gustaría mirar la línea 22de Book.javapara ver qué podría causar el error NullPointerExceptionhere.
Ejemplo más abrumador con código de biblioteca
Por lo general, los seguimientos de pila son mucho más complejos que los dos ejemplos anteriores. Aquí hay un ejemplo (es largo, pero muestra varios niveles de excepciones encadenadas):
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
En este ejemplo, hay mucho más. Lo que más nos preocupa es buscar métodos que sean de nuestro código , que serían cualquier cosa en el com.example.myprojectpaquete. En el segundo ejemplo (arriba), primero querríamos buscar la causa raíz, que es:
Caused by: java.sql.SQLException
Sin embargo, todas las llamadas a métodos que se encuentran debajo son código de biblioteca. Así que nos moveremos hasta "Causado por" arriba y buscaremos la primera llamada al método que se origina en nuestro código, que es:
at com.example.myproject.MyEntityService.save(MyEntityService.java:59)
Como en ejemplos anteriores, deberíamos mirar en MyEntityService.javalínea 59, porque ahí es donde se originó este error (este es un poco obvio lo que salió mal, ya que la SQLException indica el error, pero el procedimiento de depuración es lo que buscamos).
Estoy publicando esta respuesta, por lo que la respuesta más alta (cuando se ordena por actividad) no es una que sea simplemente incorrecta.
¿Qué es un Stacktrace?
Un stacktrace es una herramienta de depuración muy útil. Muestra la pila de llamadas (es decir, la pila de funciones que se llamaron hasta ese momento) en el momento en que se lanzó una excepción no detectada (o en el momento en que se generó el seguimiento de la pila manualmente). Esto es muy útil porque no solo le muestra dónde ocurrió el error, sino también cómo terminó el programa en ese lugar del código. Esto lleva a la siguiente pregunta:
¿Qué es una excepción?
Una excepción es lo que utiliza el entorno de ejecución para indicarle que se produjo un error. Los ejemplos más populares son NullPointerException, IndexOutOfBoundsException o ArithmeticException. Cada uno de estos se produce cuando intenta hacer algo que no es posible. Por ejemplo, se lanzará una NullPointerException cuando intente eliminar la referencia a un objeto Null:
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.
¿Cómo debo lidiar con Stacktraces / Exceptions?
Al principio, averigüe qué está causando la excepción. Intente buscar en Google el nombre de la excepción para averiguar cuál es la causa de esa excepción. La mayoría de las veces será causado por un código incorrecto. En los ejemplos anteriores, todas las excepciones se deben a un código incorrecto. Entonces, para el ejemplo de NullPointerException, puede asegurarse de que anunca sea nulo en ese momento. Podría, por ejemplo, inicializar ao incluir una verificación como esta:
if (a!=null) {
a.toString();
}
De esta forma, la línea infractora no se ejecuta si a==null. Lo mismo ocurre con los otros ejemplos.
A veces, no puede asegurarse de no obtener una excepción. Por ejemplo, si está utilizando una conexión de red en su programa, no puede evitar que la computadora pierda su conexión a Internet (por ejemplo, no puede evitar que el usuario desconecte la conexión de red de la computadora). En este caso, la biblioteca de red probablemente lanzará una excepción. Ahora debería capturar la excepción y manejarla . Esto significa que, en el ejemplo con la conexión de red, debe intentar reabrir la conexión o notificar al usuario o algo por el estilo. Además, siempre que use catch, siempre capture solo la excepción que desea capturar, no use declaraciones de captura amplias como lascatch (Exception e) que detectarían todas las excepciones. Esto es muy importante porque, de lo contrario, podría detectar accidentalmente la excepción incorrecta y reaccionar de manera incorrecta.
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!")
}
¿Por qué no debería usar catch (Exception e)?
Usemos un pequeño ejemplo para mostrar por qué no debería detectar todas las excepciones:
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;
}
}
Lo que este código está tratando de hacer es capturar el ArithmeticExceptioncausado por una posible división entre 0. Pero también captura un posible NullPointerExceptionque se lanza si ao bson null. Esto significa que puede obtener una NullPointerExceptionpero la tratará como una ArithmeticException y probablemente hará algo incorrecto. En el mejor de los casos, todavía se pierde que hubo una NullPointerException. Cosas como esa hacen que la depuración sea mucho más difícil, así que no hagas eso.
TLDR
- Averigüe cuál es la causa de la excepción y corríjala, para que no arroje la excepción en absoluto.
Si 1. no es posible, capture la excepción específica y manipúlela.
- ¡Nunca agregue un try / catch y luego ignore la excepción! ¡No hagas eso!
- Nunca use
catch (Exception e), siempre capture Excepciones específicas. Eso le ahorrará muchos dolores de cabeza.
Para agregar a lo que Rob ha mencionado. Establecer puntos de interrupción en su aplicación permite el procesamiento paso a paso de la pila. Esto permite al desarrollador usar el depurador para ver en qué punto exacto el método está haciendo algo inesperado.
Dado que Rob ha utilizado NullPointerException(NPE) para ilustrar algo común, podemos ayudar a eliminar este problema de la siguiente manera:
si tenemos un método que toma parámetros como: void (String firstName)
En nuestro código querríamos evaluar que firstNamecontiene un valor, haríamos esto así:if(firstName == null || firstName.equals("")) return;
Lo anterior nos impide usarlo firstNamecomo parámetro inseguro. Por lo tanto, al hacer comprobaciones nulas antes del procesamiento, podemos ayudar a garantizar que nuestro código se ejecute correctamente. Para ampliar un ejemplo que utiliza un objeto con métodos, podemos mirar aquí:
if(dog == null || dog.firstName == null) return;
El anterior es el orden correcto para verificar si hay nulos, comenzamos con el objeto base, perro en este caso, y luego comenzamos a caminar por el árbol de posibilidades para asegurarnos de que todo sea válido antes del procesamiento. Si se invirtiera la orden, podría lanzarse una NPE y nuestro programa colapsaría.
Hay una característica más de seguimiento de pila ofrecida por la familia Throwable: la posibilidad de manipular la información de seguimiento de pila.
Comportamiento estándar:
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();
}
}
Seguimiento de pila:
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)
Seguimiento de pila manipulado:
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();
}
}
Seguimiento de pila:
Exception in thread "main" java.lang.RuntimeException
at OtherClass.methodX(String.java:99)
at OtherClass.methodY(String.java:55)
Para entender el nombre : un seguimiento de pila es una lista de excepciones (o puede decir una lista de "Causa por"), desde la excepción más superficial (por ejemplo, la excepción de la capa de servicio) hasta la más profunda (por ejemplo, la excepción de la base de datos). Al igual que la razón por la que lo llamamos 'pila' es porque la pila es First in Last out (FILO), la excepción más profunda ocurrió al principio, luego se generó una cadena de excepciones, una serie de consecuencias, la excepción de superficie fue la última uno sucedió en el tiempo, pero lo vemos en primer lugar.
Clave 1 : Algo complicado e importante que hay que entender aquí es: la causa más profunda puede no ser la "causa raíz", porque si escribe algún "código incorrecto", puede causar alguna excepción debajo que es más profunda que su capa. Por ejemplo, una consulta SQL incorrecta puede hacer que la conexión SQLServerException se restablezca en el bottem en lugar del error syndax, que puede estar justo en el medio de la pila.
-> Localizar la causa raíz en el medio es tu trabajo.
Clave 2 : Otra cosa complicada pero importante está dentro de cada bloque "Cause by", la primera línea era la capa más profunda y pasa el primer lugar para este bloque. Por ejemplo,
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 fue llamado por Auther.java:25 que fue llamado por Bootstrap.java:14, Book.java:16 fue la causa raíz. Aquí adjunte un diagrama para ordenar la pila de trazas en orden cronológico.
Solo para agregar a los otros ejemplos, hay clases internas (anidadas) que aparecen con el $signo. Por ejemplo:
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();
}
}
Dará como resultado este seguimiento de pila:
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)
Las otras publicaciones describen qué es un seguimiento de pila, pero aún puede ser difícil trabajar con él.
Si obtiene un seguimiento de pila y desea rastrear la causa de la excepción, un buen punto de partida para comprenderlo es utilizar la consola de seguimiento de pila de Java en Eclipse . Si usa otro IDE, puede haber una característica similar, pero esta respuesta es sobre Eclipse.
Primero, asegúrese de tener todas sus fuentes de Java accesibles en un proyecto de Eclipse.
Luego, en la perspectiva de Java , haga clic en la pestaña Consola (generalmente en la parte inferior). Si la vista de la consola no está visible, vaya a la opción de menú Ventana -> Mostrar vista y seleccione Consola .
Luego, en la ventana de la consola, haga clic en el siguiente botón (a la derecha)
y luego seleccione Java Stack Trace Console en la lista desplegable.
Pega el seguimiento de tu pila en la consola. A continuación, proporcionará una lista de enlaces a su código fuente y cualquier otro código fuente disponible.
Esto es lo que puede ver (imagen de la documentación de Eclipse):
La llamada al método más reciente realizada será la parte superior de la pila, que es la línea superior (excluyendo el texto del mensaje). Bajar la pila retrocede en el tiempo. La segunda línea es el método que llama a la primera línea, etc.
Si está utilizando software de código abierto, es posible que deba descargar y adjuntar a su proyecto las fuentes si desea examinar. Descargue los archivos de origen, en su proyecto, abra la carpeta Bibliotecas de referencia para encontrar su archivo de código abierto para su módulo de código abierto (el que tiene los archivos de clase), luego haga clic derecho, seleccione Propiedades y adjunte el archivo de origen.