NullPointerException en Java sin StackTrace

Question

he tenido casos de nuestra coger un código Java NullPointerException, pero cuando intento acceder al StackTrace (que básicamente termina llamando Throwable.printStackTrace()), todo lo que consigo es:

java.lang.NullPointerException 

¿Alguien más se ha encontrado con esto? Intenté buscar en Google "rastro de pila vacía de puntero java" pero no encontré nada como esto.

Answer 1

Probablemente esté utilizando Sun JVM, que realiza una gran cantidad de optimización. Para recuperar los restos de la pila, debe pasar la opción -XX:-OmitStackTraceInFastThrow a la JVM.

Answer 2

exception.toString no le da la StackTrace, que sólo devuelve

una breve descripción de esta throwable. El resultado es la concatenación de:

* the name of the class of this object 
* ": " (a colon and a space) 
* the result of invoking this object's getLocalizedMessage() method 

---

Uso exception.printStackTrace lugar a la salida de la StackTrace.

Answer 3

toString() solo devuelve el nombre de la excepción y el mensaje opcional. Yo sugeriría llamando

exception.printStackTrace() 

para volcar el mensaje, o si necesita los detalles morbosos:

StackTraceElement[] trace = exception.getStackTrace() 

Answer 4

Esta es la salida de la excepción, utilice exclusivamente para depurar debe manejar excepciones que mejor.

import java.io.PrintWriter; 
import java.io.StringWriter; 
    public static String getStackTrace(Throwable t) 
    { 
     StringWriter sw = new StringWriter(); 
     PrintWriter pw = new PrintWriter(sw, true); 
     t.printStackTrace(pw); 
     pw.flush(); 
     sw.flush(); 
     return sw.toString(); 
    } 

Answer 5

Como mencionaste en un comentario, estás usando log4j. He descubierto (sin querer) un lugar en el que había escrito

LOG.error(exc); 

en lugar de la típica

LOG.error("Some informative message", e); 

por pereza o tal vez simplemente no pensar en ello. La parte desafortunada de esto es que no se comporta como esperabas. La API de registrador realmente toma Object como el primer argumento, no una cadena, y luego llama aString() en el argumento. Entonces, en lugar de obtener el bonito y bonito seguimiento de pila, simplemente imprime el toString, que en el caso de NPE es bastante inútil.

Quizás esto es lo que estás experimentando?

Answer 6

sugerencia alternativa - si estás usando Eclipse, podría establecer un punto de interrupción en sí NullPointerException (! En la perspectiva de depuración, vaya a la pestaña "puntos de ruptura" y hacer clic en el pequeño icono que tiene un en ella)

Comprueba las opciones "capturadas" y "no detectadas": ahora cuando disparas el NPE, de inmediato lo rompes y luego puedes ver cómo exactamente se maneja y por qué no obtienes un seguimiento de pila.

Answer 7

(Su pregunta aún no está clara si su código está llamando al printStackTrace() o si lo está haciendo un manejador de registro.)

Estas son algunas posibles explicaciones sobre lo que podría estar sucediendo:

• El registrador/controlador que se utiliza se ha configurado para la salida única cadena del mensaje de la excepción, no una traza completa.

• Su aplicación (o una biblioteca de terceros) está registrando la excepción utilizando LOG.error(ex); en lugar de la forma de 2 argumentos (por ejemplo) del método Log4j Logger.

• El mensaje viene de un lugar diferente al que cree que es; p.ej. en realidad viene algún método de biblioteca de terceros, o algunas cosas aleatorias sobrantes de intentos anteriores de depurar.

• La excepción que se está registrando ha sobrecargado algunos métodos para ocultar el stacktrace. Si ese es el caso, la excepción no será una NullPointerException genuina, sino que será un subtipo personalizado de NPE o incluso alguna excepción no conectada.

creo que la última explicación posible es muy poco probable, pero la gente lo menos contemplar haciendo este tipo de cosas "prevenir" ingeniería inversa. Por supuesto, solo tiene éxito al dificultar la vida de los desarrolladores honestos.

Answer 8

Hemos visto este mismo comportamiento en el pasado. Resultó que, por algún loco motivo, si una NullPointerException ocurría en el mismo lugar en el código varias veces, después de un tiempo usando Log.error(String, Throwable) se detendrían incluidos los rastros de pila completa.

Intente mirar más atrás en su registro. Puede encontrar al culpable.

EDIT:this bug sonidos relevantes, pero se fijó hace tanto tiempo que probablemente no es la causa.

Answer 9

Aquí es una explicación: Hotspot caused exceptions to lose their stack traces in production – and the fix

Lo he probado en Mac OS X

• java version "1.6.0_26"
• Java (TM) SE Runtime Environment (build 1.6. 0_26-b03-383-11A511)

• Java HotSpot (TM) de 64 bits del servidor VM (build 20.1-b02-383, modo mixto)

  Object string = "abcd"; 
  int i = 0; 
  while (i < 12289) { 
      i++; 
      try { 
       Integer a = (Integer) string; 
      } catch (Exception e) { 
       e.printStackTrace(); 
      } 
  } 
  

Para este fragmento de código específica, 12288 iteraciones (+ frecuencia?) Parece ser el límite en el que la JVM ha decidido utilizar excepción preasignado ...

Answer 10

Cuando está utilizando AspectJ en su proyecto, puede suceder que algún aspecto oculte su parte del seguimiento de la pila.Por ejemplo, hoy tuve:

java.lang.NullPointerException: 
    at com.company.product.MyTest.test(MyTest.java:37) 

Este rastro de pila se imprimió al ejecutar la prueba a través del seguro de Maven.

Por otro lado, cuando se ejecuta la prueba de IntelliJ, un seguimiento de pila diferente fue impreso:

java.lang.NullPointerException 
    at com.company.product.library.ArgumentChecker.nonNull(ArgumentChecker.java:67) 
    at ... 
    at com.company.product.aspects.CheckArgumentsAspect.wrap(CheckArgumentsAspect.java:82) 
    at ... 
    at com.company.product.MyTest.test(MyTest.java:37)