RTFS: Read The F.... Stacktrace
Tal vez hayas leido del acronimo RTFM, se utiliza en tipicamente (sobre todo en los foros de internet) cuando se le quiere indicar a alguien que para responder a su pregunta todo lo que tendria que haber hecho es leer el manual.
Bueno, quisiera proponerles un nuevo acronimo que me comento una amigo cuando estabamos platicando sobre los problemas a los que nos enfretamos todos los dias cuando estamos desarrollando: RTFS, la S es the StackTrace.
Cuando una aplicacion de Java se traba, en el 99% de los casos (a menos que le hayas logrado pegar a un bug de bajo nivel de la maquina virtual, cosa que ocurre muy pero muy rara vez) la aplicacion te presentara a una StackTrace que te permitira saber no solamente en que linea ocurrio el problema, si no tambien que metodo(s) estaban llamando al metodo dentro del cual ocurrio el problema.
Digamos por ejemplo que tenemos el metodo:
Que ocurre cuando el parametro object1 es null? Pues una NullPointerException, que se nos presentara de la siguiente forma:
Exception in thread "main" java.lang.NullPointerException at JavaSnippet$1.equals(JavaSnippet.java:5) at JavaSnippet$1.run(JavaSnippet.java:11) at JavaSnippet.main(JavaSnippet.java:14)
Ahi podemos ver que el error ocurrio en la linea 5 del archivo “JavaSnippet.java”, cuando la linea 11 del mismo archivo fue invocada por la la linea 14, inclusive nos dice a que metodo pertenece cada linea de ejecucion!
Como ven, saber exactamente que linea causo un problema en java es algo muy facil, por que las excepciones incluyen la informacion de todo el camino que siguio la ejecucion del problema hasta el punto en que ocurrio la excepcion que interrmpio la ejecucion normal del programa: En el pasado quedaron los dias cuando al programar en C, C++ o Delphi y cometer el error de acceder un objeto no inicializado lo unico que veiamos era un mensaje del tipo:
0xC1114455 Access Violation Error
Ahi si que era mas dificil averiguar (aunque no siempre imposible si se contaba con las herramientas correctas y la memoria no estaba demasiado corrupta) exactamente en donde y por que habia ocurrido el problema.
Pero aun con lo facil que es saber donde y por que ocurrio un problema en Java, aun me encuentro muchos mensajes en los foros de programacion del tipo:
“Hice una aplicacion con que hace XXXX usando XXXX pero lanza una excepcion y se traba: ¿como lo compongo?”
Y ya, eso es todo lo que ponen, y la stacktrace, que deberia ir copiada y pegada siempre que se necesita ayuda para resolver este tipo de probemas? Esa brilla por su ausencia!. Mas de la mitad de las veces he resuelto el problema simplemente contestando: Podrias mostrarme la stacktrace? Y luego simplemente leyendosela a la persona... pero a veces se me antoja simplemente poner RTFS!
A las personas que hacen este tipo de preguntas muchas veces les sorprende que nadie les conteste, lo que no saben es que la mayoria de las personas en los foros, al ver una pregunta para la cual el autor ni siquiera se molesto en agregar el stacktrace, piensa: "Esta persona no tiene ni siquiera el nivel de conocimientos para saber que la respuesta a su pregunta esta frente a su cara, no tiene caso que le conteste, por que igual no va entender la respuesta, y solo conseguire frustrarme" y la dejan sin contestar.
- blog de luxspes
- Inicie sesión o regístrese para enviar comentarios
aquí mismo...
y que tal esas dudas de tipo "es que mi programa no corre, me sale este error" y pegan el stack trace... aqui he visto algunos posts asi (mañana busco algunos y pego aqui las ligas, ahorita me da flojera la verdad). Creo que ahi se puede justificar 100% un RTFS. Según yo hace poco (esta semana) vi uno así.
Ademas el formato de Stack Trace es útil incluso en los casos en que se optimizó la compilación y no incluye números de linea ya el .class; sigue apareciendo el nombre de la clase y el método, lo cual ya es bastante útil para enfocarse a buscar la posible causa dentro de dicho método.
Estoy de acuerdo, aunque
Estoy de acuerdo, aunque leer el stacktrace puede resultar confuso para los novatos que a duras penas si pueden leer código... y peor si les da la sensación que la información que brinda no ayuda de mucho, en el sentido que dice donde falla pero no como corregirlo. También en ocasiones la "culpa" de error no la tiene el código sino el contenedor u otro agente externo pero el Stacktrace no lo indica claramente, cosa que para quien no tiene experiencia no le ayuda en nada. En esos casos conviene leer también el log de los contenedores lo cual también implica leer mas stacktrace...
Lo que queda entonces es hacerles ver que que si bien leer el stacktrace por si solo no resuelve las cosas, mas cierto es que es un muy buen punto de inicio, por lo que alguien llegue con una duda y ni siquiera a mirado el stacktrace (al menos por curiosidad) es imperdonable. El segundo paso es pues aprender a interpretarlos, cosa obvia para algunos pero no para todos, y el tercero aprender a identificar errores comunes o frecuentes, éste último solo lo dá la experiencia, misma que sin embargo también puede ser consultada.
Saludos.
RTFSC: Read the F.... Source Code!
Se a lo que te refieres, es cuando ocurre el problema inverso, alguien entra a un foro y pone la pregunta:
Lo primero que le contesto (si ando con paciencia ese dia) es: Sabes lo que significa el StackTrace? y luego: ¿Que dice la linea de codigo 5 del archivo JavaSnippet.java?
Y me contesta:
Ahora, cuando es algún otro tipo de excepcion, 1 sola linea puede no ser suficiente para diagnoticarla, pero en el caso de una NullPointerException es muy simple significa que trataste de efectuar una operación sobre un objeto nulo. Por supuesto, si les contesto eso, invariablemente (si es en persona) se me quedan viendo con cara de "what?" y si es en linea me contestan que "no entienden de esos rollos, que apenas estan aprendiendo y que que significa eso de "objeto nulo""
Asi que he encontrado un modo mas sencillo de explicarlo:
Ese error ocurrio por que la variable antes del "." no esta inicializada, asi que ve a la linea 5 (que es la que indica el stracktrace) y averigua por que la variable antes del "." en esa linea no tiene ningun valor, haz que tenga valor, y asunto resuelto.
Por supuesto, a veces resulta que la linea con el problema es algo como:
Una linea asi, sobretodo para alguien sin experiencia, resulta todo un misterio, tiene demasiados "." (puntos) de fallo que pueden producir la NullPointerException.... y como encontrar la solucion implicaria tener que leer todo el codigo de la persona con el problema (y en donde trabajo a veces eran 4 o 5 personas las que tenian este problema al mismo tiempo), pues he optado por una estrategia mas directa:
"Mira, tu linea tiene demasiados puntos, cada punto es un posible causante de la NullPointerException" asi que por favor, partela en pedacitos, asi:
String calleUsuario = direccionUsuario.getCalle();
List sucursalesCompañia = compañia.getSucursales();
Sucursal sucursalCompañia = sucursalesCompañia.get(0);
Direccion direccionSucursal = sucursalCompañia.getDireccion();
String calleCompañia = direccionSucursal.getCalle();
return calleUsuario.equals(calleCompañia );
Y correlo otra ves, y en la linea que te truene, checa por la que la variable antes del unico "." no tiene ningun valor, corrige el codigo para que tenga valor, o agrega una condicional para evitar que esa linea se ejecute si la variable no tiene valor.
Y funciona como magia, despues de eso, nunca vuelven a tener problemas con las NullPointerException... ojala hubiera una solucion tan facil para todos los tipos de excepciones posibles...
jstack
Otra razón muy importante por la cual es necesario saber leer un stack trace es para poder depurar situaciones de deadlock con jstack.
Si no lo han usado, jstack es una herramienta muy útil que imprime el stack trace de cada hilo de una aplicación que está corriendo. De ese modo pueden ver lo que está ocurriendo en cada hilo en ese momento, y si tienen algún problema de que su aplicación de repente se traba y sospechan que puede ser un problema de sincronización de procesos (algun deadlock) con esto lo pueden encontrar, viendo el status de cada hilo para encontrar los que digan
BLOCKED (on object monitor)y ver si hay alguna relación entre dos (o más) hilos en el mismo status.genial no lo habia visto
genial no lo habia visto pero ahora sera RTFS