¿Cómo se depura Android inEclipse

Question

intente lo siguiente:

1. crear una aplicación HelloWorld.

2. Añadir una declaración de registro al final de onCreate:

 
    public void onCreate(Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
     setContentView(R.layout.main); 
     Log.d("HelloWorldActivity.onCreate()", "setContentView() completed"); 
    } 

1. Coloque un punto de interrupción en la declaración de registro.

2. Ejecute la aplicación en el emulador y tenga en cuenta que funciona y el paso para ver la entrada registrada en la ventana LogCat de Eclipse.

3. Cambia HelloWorldActivity para extender desde ListActivity en lugar de Activity.

    
   public class HelloWorldActivity extends ListActivity { 
   

4. Ejecute de nuevo la aplicación en el emulador y observe que no puede alcanzar la instrucción de registro.

Mi pregunta NO es por qué esto falla. Mi pregunta es, ¿cómo harías para depurar este error? Todo lo que veo en el panel Eclipse Debug es una RuntimeException. Veo que LogCat tiene un montón de mensajes, pero es enorme y lo he buscado, pero no puedo encontrar nada que indique lo que está mal o en qué parte de mi código se produjo la excepción. No puedo encontrar una manera de mostrar el mensaje dentro de RuntimeException o un seguimiento de pila para saber qué línea de código inició la excepción.

Supongo que debe haber mejores formas de utilizar las herramientas para encontrar errores, pero soy nuevo y no puedo encontrar una mejor manera de depurar, además de ajustar todo lo que codigo en un try/catch. Hubiera esperado encontrar un mensaje en LogCat generado al arrojar la excepción. Hubiera esperado que la ventana de depuración le permitiera inspeccionar los contenidos de la excepción. No estoy diciendo que tales técnicas no existan, estoy diciendo que estoy teniendo problemas para descubrir como principiante cómo depurar y preguntar qué técnicas existen y cómo las uso.

Así, en pocas palabras:

• ¿Cómo encontrar este error si no ya sabe lo que estaba causando?
• ¿Qué técnicas usarías para descubrir la causa raíz?
• ¿Cómo harías para inspeccionar los detalles de la Excepción?
• Generalmente, ¿cómo encuentras problemas en tu código de Android usando Eclipse?

Se aceptan sugerencias y debates. :)

Hubiera incluido mis contenidos de LogCat, pero es tan grande que no es razonable. Deberías poder reproducir esto fácilmente, así que lo dejé fuera. Es posible que algo en LogCat me ayude, pero debido a que es tan grande que incluso ejecuta un programa pequeño, necesitaría una pista sobre qué buscar y cómo interpretarlo cuando toco una excepción lanzada desde una llamada API. Veo otras publicaciones que dicen que algo debería estar en LogCat, que aunque podría ser cierto, no encontraré nada por mi cuenta. Si cree que algo debe estar en LogCat, ejecute la prueba usted mismo y copie las líneas en su respuesta que debería encontrar.

Gracias.

========

lista de técnicas Resumen hasta ahora es la siguiente:

técnicas invasivas: 1. Coloque un brindis en ubicaciones de código en la que desea ver que usted tiene ejecutado. 2. Ponga el código try/catch alrededor donde cree que hay una posibilidad de que se genere una excepción. 3. Comente el código y vuelva a compilar y volver a probar.

Técnicas no invasivas: 1. Utilice el depurador. Puntos de corte, inspección variable ... 2. Comprobador de esfuerzo mono. 3. Descargue la biblioteca de origen de Android. 4. Use los filtros de LogCat para ver si aparece una "Causa por".

No está claro si está disponible: 1. Versión de depuración de la biblioteca de Android que tiene registro adicional, aserciones u otra ayuda adicional. 2. Capacidad para inspeccionar una excepción en Eclipse a través del panel Depurar u otras técnicas. 3. Una forma de definir un controlador de excepción try/catch más global. 4. Posibilidad de depurar a través del código fuente de la biblioteca Android.

No disponible: 1. Una forma no invasiva de ver el contenido de una excepción o donde ocurrió la excepción.

Answer 1

hey, Ineresting question. Bueno, primer consejo, puedes filtrar lo que Logcat te dice. Por ejemplo, usted hace que solo muestre los errores al hacer clic en rojo (e). También le dice dónde ocurrió el error si ejecuta su aplicación en modo de depuración. Puede dirigirlo directamente a su código o a sdk de Android. Saber qué paquete de Android causó el error es de gran ayuda.

Estos dos simplemente vienen a mi mente. ¡Espero eso ayude!

Answer 2

En general, si algo arroja una excepción, entonces probablemente debería estar atendiendo esa situación de todos modos, sin embargo, poner bloques try/catch es una forma decente de encontrar el problema específico. Descubrí que si no coloca algo en el bloque catch, entonces no puede evaluar la excepción en la ventana de variables de observación en eclipse. Así que siempre pongo una llamada de registro y establezco un punto de interrupción en esa línea.

public void onCreate(Bundle savedInstanceState) { 
    try{ 
     super.onCreate(savedInstanceState); 
     setContentView(R.layout.main); 
    }catch(Exception exception) 
    { 
     // put break point on line below so you can evaluate exception in debug mode. 
     Log.e(TAG, "Set content exception "+ exception.getMessage()); 
     // note some exceptions return null on getMessage(); 
    } 
    Log.d("HelloWorldActivity.onCreate()", "setContentView() completed"); 
} 

Así que si su rastro de pila es enorme, entonces esto ayudará. Otros desarrolladores también han encontrado que obtener el código fuente para el SDK significa que puedes ver dónde se arrojó el error en el código SDK principal. No he hecho esto sin embargo.

Answer 3

Las excepciones no detectadas con try/catch son errores y rompen el flujo normal del programa.

Ejecutar en modo de depuración es simplemente hacer clic en el botón de error. No sé si hay bibliotecas de depuración "especiales". Pero cuando se trabaja con Android, todas las "bibliotecas" son de código abierto, por lo que puede ver prácticamente cualquier cosa.

Lo bueno del modo de depuración es que, cuando se produce un error, su aplicación se congela en el limbo cuando se produce el error. Puede establecer puntos de interrupción establecidos, cambiar su código sobre la marcha mientras se ejecuta su programa, lo cual es genial (Bueno, no puede hacer cambios drásticos como cambiar el nombre de un método).

La forma en que se tratan los errores y errores en Android, sin embargo, puede ser un poco diferente de .NET, ya que el modelo en cada uno es diferente.

Al programar en Windows, las aplicaciones funcionan como islas pequeñas. Usted tiene un control directo sobre el flujo de código (es decir, puede llamar a un diálogo modal para congelar el flujo de código mientras el usuario ingresa algunos datos) y puede hacer un programa totalmente funcional usando solo un hilo. En Android casi todo se ejecuta en su propia sincronización. Y su aplicación debe estar preparada para manejar cosas como recibir una llamada telefónica en el medio de la ejecución. Por lo tanto, puede aplicar este modelo a la depuración también: Errors (that happen due to unforsen circumstances) tend to propagate much more than in other development ambient. La forma en que se manejan esos errores también es diferente: esto es evidente cuando te das cuenta de que tu aplicación aún se ejecuta incluso después de lanzar una excepción.

consejos Algunos más útiles: que tenga una muy poderosa herramienta llamada mono, una herramienta que genera el estrés "corrientes pseudo-aleatorios de eventos de usuario tales como clics, toques o gestos, así como una serie de sistema- eventos de nivel ".

LogCat indica la "causa" del error. La línea generalmente comienza con Caused By. Si está interesado en la causa más que en la consecuencia, puede filtrar aún más sus informes de error buscando "Causado por".

Por último, pero no por eso menos importante, encuentro el viejo método de comentar líneas y ver qué sucede para resolverlo.

creo que sirve

Answer 4

yo estaba corriendo en el mismo tema y encontró lo siguiente por Steve H. que ayudó:

Lo que sucede es que cuando el depurador se adjunta, los registros de excepción no se publique en LogCat hasta que finalice la aplicación desde dentro de la perspectiva de depuración. Esto sucede porque la aplicación no se bloquea hasta que se despega el depurador . - Steve H 31 de marzo a las 15:47

------ sí, eso lo hizo. Ahora veo la misma excepción. DESPUÉS de permitir que el programa se ejecute, se bloquea por completo y sale el proceso. Debería mostrar esa información cuando detiene mi programa y muestra las pantallas del depurador IDE. No me deje pensando y perdiendo mi tiempo con más haciendo clic en alrededor. Eclipse tiene un largo camino por recorrer, parece para competir con los gustos de Visual Studio. Esperemos que mi paciencia por ello dura más que mi proyecto. Gracias por la retroalimentación . :) - Sebastian Dwornik Mar 31 a 17:35

Enlace a la pregunta: What's wrong with debugging in Eclipse on Android?