hilo saliendo con excepción no detectada: NO stack trace

Question

Mi aplicación está causando una fuerza cercana en algún lugar pero en lugar de obtener una EXCEPCIÓN FATAL con el rastro de pila habitual (y muy informativo) en mi LogCat, solo recibo las siguientes 4 líneas:

06-27 07:08:54.546: D/dalvikvm(14351): GC_FOR_MALLOC freed 9923 objects/657416 bytes in 21ms 
06-27 07:08:54.769: W/dalvikvm(14351): threadid=20: thread exiting with uncaught exception (group=0x4001d7f0) 
06-27 07:08:54.796: W/dalvikvm(14351): threadid=21: thread exiting with uncaught exception (group=0x4001d7f0) 
06-27 07:08:54.796: I/Process(14351): Sending signal. PID: 14351 SIG: 9 

¡Esto está en el modo DEPURAR sin aplicar FILTROS en el LogCat!

• ¿Qué podría estar causando este comportamiento?
• ¿Hay alguna forma de saber qué está causando esta excepción?

Actualización: Gracias a @assylias abajo, que han sido capaces de poner en práctica:

final UncaughtExceptionHandler subclass = Thread.currentThread().getUncaughtExceptionHandler(); 
Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() { 
    @Override 
    public void uncaughtException(Thread paramThread, Throwable paramThrowable) { 
    Log.getStackTraceString(paramThrowable); 

    subclass.uncaughtException(paramThread, paramThrowable); 
    } 
}); 

que produjo estas líneas añadidas:

06-27 08:24:47.105: D/dalvikvm(15475): GC_FOR_MALLOC freed 13865 objects/1435952 bytes in 45ms 
06-27 08:24:47.136: I/dalvikvm(15475): threadid=15: stack overflow on call to Ljava/lang/AbstractStringBuilder;.enlargeBuffer:VI 
06-27 08:24:47.136: I/dalvikvm(15475): method requires 28+20+20=68 bytes, fp is 0x45209338 (56 left) 
06-27 08:24:47.140: I/dalvikvm(15475): expanding stack end (0x45209300 to 0x45209000) 
06-27 08:24:47.140: I/dalvikvm(15475): Shrank stack (to 0x45209300, curFrame is 0x4520937c) 
06-27 08:24:47.159: I/dalvikvm(15475): threadid=16: stack overflow on call to Ljava/lang/AbstractStringBuilder;.enlargeBuffer:VI 
06-27 08:24:47.159: I/dalvikvm(15475): method requires 28+20+20=68 bytes, fp is 0x4520c338 (56 left) 
06-27 08:24:47.167: I/dalvikvm(15475): expanding stack end (0x4520c300 to 0x4520c000) 
06-27 08:24:47.167: I/dalvikvm(15475): Shrank stack (to 0x4520c300, curFrame is 0x4520c37c) 
06-27 08:24:47.175: I/dalvikvm(15475): threadid=17: stack overflow on call to Ljava/lang/AbstractStringBuilder;.enlargeBuffer:VI 
06-27 08:24:47.175: I/dalvikvm(15475): method requires 28+20+20=68 bytes, fp is 0x4520f338 (56 left) 
06-27 08:24:47.175: I/dalvikvm(15475): expanding stack end (0x4520f300 to 0x4520f000) 
06-27 08:24:47.175: I/dalvikvm(15475): Shrank stack (to 0x4520f300, curFrame is 0x4520f37c) 

Ésta es sin duda mucho más útil información, pero ahora estoy luchando con lo siguiente:

• La aplicación no se cierra forzosamente ahora, a pesar de la llamada al subclass.uncaughtException(). ¿Por qué?
• ¿Cuál es el significado de todos los desbordamientos de pila? ¿Qué podría estar haciendo eso es tan agotador en mi pobre dispositivo de prueba de Android?
• ¿Cómo puedo saber qué parte de mi código causa esto?

Actualización:Log.getStackTraceString(paramThrowable); era en realidad no imprimir nada. La impresión extra que recibí era de bogus subclass.uncaughtException (paramThread, paramThrowable); La forma correcta de registrar el seguimiento completo de la pila es usando Log.e(TAG, "uncaughtException", throwable).

La única pregunta que queda ahora es ¿cómo puedo volver a lanzar la excepción? Solo haz un throw paramThrowable?

Respondiendo a mi última pregunta: Eclipse no me deja tirar sin rodear con try/catch, lo que me llevó a entender que lo que quiero no es un re-lanzamiento sino un killProcess(). Problema resuelto.

Answer 1

También podemos establecer una excepción no capturada por defecto al comienzo de su aplicación y registrar algunos datos allí (el ejemplo siguiente se utiliza un registrador de java, pero fácil de incorporar a Android):

private static void setDefaultUncaughtExceptionHandler() { 
    try { 
     Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() { 

      @Override 
      public void uncaughtException(Thread t, Throwable e) { 
       logger.error("Uncaught Exception detected in thread {}", t, e); 
      } 
     }); 
    } catch (SecurityException e) { 
     logger.error("Could not set the Default Uncaught Exception Handler", e); 
    } 
} 

Answer 2

esto va a ser tedioso, pero me gustaría pasar solo hasta que se rompa con el depurador. a continuación, se puede añadir una captura más general

catch (Exception e) {}

Todas las excepciones se extienden desde Excepción por lo que puede ayudar a diagnosticar más estás problema.

Una idea más, tal vez su aplicación está ejecutando la memoria del dispositivo. La JVM podría estar matando a su aplicación sin avisarle debido a un cierre de JVM en caso de error de memoria.

Answer 3

Sé que esto es antiguo, pero si alguien más desea saber cómo salir de manera normal después de tratar con la excepción no detectada:

final Thread.UncaughtExceptionHandler androidDefaultUEH = Thread.getDefaultUncaughtExceptionHandler(); 

Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() { 
      @Override 
      public void uncaughtException(final Thread thread, final Throwable ex) { 
       // Handle exception however you want, then: 
       androidDefaultUEH.uncaughtException(thread, ex); 
      } 
     });