¿Qué pasa con la depuración en Eclipse en Android?

Question

Duplicar posible:
Seemingly useless debugging environment for Android

Obviamente he estado arruinado por Visual Studio, porque a pesar de que estoy aprendiendo Android y el entorno Eclipse, aplicaciones de depuración de Eclipse está convirtiendo en una grave detrimento para un mayor desarrollo.

Por ejemplo, Eclipse recopilará esta división por cero bien:

public class Lesson2Main extends Activity 
{ 
    /** Called when the activity is first created. */ 
    @Override 
    public void onCreate(Bundle savedInstanceState) 
    { 
     super.onCreate (savedInstanceState); 

     int i = 1/0; 

     TextView tv = new TextView (this); 
     tv.setText ("Hello, Android!"); 
     setContentView (tv); 
    } 
} 

Y luego, cuando se ejecuta en el depurador, que tendrá una pantalla completa de información de depuración inútil, no de que en realidad me señala la línea específica que contiene el error.

stackTrace es nulo dentro del árbol de información de excepción ('e'), y simplemente indica un mensaje que indica 'ArithmeticException'. (eso es bueno, ¿qué tal si me señalas dónde lo encontraste ?!)

Miré por toda la pantalla y estoy desconcertado de que este IDE no pueda entenderlo bien. ¿Desarrollar con Eclipse recurrir a todos a 1991 con printf() como iniciar sesión en cada intervalo y luego buscar errores? Seriamente.

¿Existe alguna configuración o complemento que me falte para ayudar con esto?

No he probado este caso con XCode, pero si el iPhone dev. IDE maneja esto más como Visual Studio, entonces no es de extrañar que el mercado de Android tenga tan pocas aplicaciones.

Estoy entusiasmado con Android, pero parece que Eclipse se interpone en el camino.

Answer 1

Sí, te has perdido uno de los complementos muy importantes para Eclipse llamado "LogCat". Captura todos los registros de depuración que proporciona tu programa Android, ya sea que se ejecute en el emulador o en un teléfono real. Esto último obviamente requiere que el teléfono esté conectado a la computadora, y menos, obviamente, la configuración en Aplicación -> Desarrollo -> Habilitar depuración de USB estará habilitada.

Los mensajes de LogCat le dan el desglose completo de lo que causó el error, incluido el número de línea. Para abrir LogCat en Eclipse, vaya a Ventana -> Mostrar vista -> Otro -> Android (una de las carpetas de la lista) -> LogCat. A continuación, coloque la ventana LogCat en algún lugar donde pueda verla fácilmente, y Eclipse recordará esa ubicación y la abrirá nuevamente la próxima vez que la inicie.

(A veces LogCat y el emulador se desconectan uno del otro La forma más sencilla de arreglar eso es sólo para cerrar Eclipse y el emulador, a continuación, reinicie los dos..)

Answer 2

Usted está experimentando un problema típico de desarrollo con un dispositivo físico en lugar de un software en una máquina.

Te señalará el error específico (Publica la información y podemos mostrarte) Solo busca los nombres de tus paquetes en el error que mostrará dónde se produjo la excepción.

También debe usar los puntos de interrupción para recorrer el proceso y ver qué pasa con que el depurador DDMS cumpla con todos sus requisitos necesarios.

Y sí, debe usar el registro Log.i (TAG, "Información:" + x);

No puede predecir todo lo que sucede y a medida que su base de códigos crece, se alegrará de haber empezado a hacerlo antes.

Answer 3

me sale el siguiente seguimiento de la pila en Logcat:

03-31 17:01:11.272: ERROR/AndroidRuntime(205): java.lang.RuntimeException: Unable to start activity ComponentInfo{MyClass}: java.lang.ArithmeticException: divide by zero 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2401) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2417) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.app.ActivityThread.access$2100(ActivityThread.java:116) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1794) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.os.Handler.dispatchMessage(Handler.java:99) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.os.Looper.loop(Looper.java:123) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.app.ActivityThread.main(ActivityThread.java:4203) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at java.lang.reflect.Method.invokeNative(Native Method) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at java.lang.reflect.Method.invoke(Method.java:521) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:791) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:549) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at dalvik.system.NativeStart.main(Native Method) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205): Caused by: java.lang.ArithmeticException: divide by zero 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at MyClass.onCreate(MyClass.java:40) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1123) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2364) 
03-31 17:01:11.272: ERROR/AndroidRuntime(205):  ... 11 more 

Esto es claro como el cristal. Mire la causa de la excepción en la línea 14 del seguimiento de pila y dice: Dividir por cero. Eso es lo que has hecho mal. La siguiente línea dice: en MyClass.onCreate (MyClass.java:40) Esta sería la línea en la que se produce la excepción. No entiendo lo que sería difícil o inútil al respecto. ¿Cómo lo presentaría VS?

Answer 4

(Hay mucho que decir en un comentario, así que estoy escribiendo esto como una respuesta.)

Puede configurar Eclipse para detener sobre las excepciones que se capturan, sin capturar, o ambos. De forma predeterminada, Eclipse se dividirá en cualquier excepción no detectada e ignorará todas las excepciones detectadas (es decir, cualquier cosa que se enganche en un bloque try/catch).

Las cosas se ponen un poco raras en Android porque se está ejecutando en un marco de aplicación, no en una aplicación independiente. Como puede ver en el seguimiento de pila publicado anteriormente, la excepción fue capturada por ActivityThread. Esto significa que su excepción inicial se considera "atrapada", y no desconectará el manejo de Eclipse hasta que ActivityThread lo vuelva a lanzar. Por esta razón, la pila que ve en el depurador cuando se detiene no está cerca de su código.

Como sabe que obtiene una ArithmeticException, puede hacer que se rompa en instancias "atrapadas" de esa excepción, y se detendrá en el punto del lanzamiento. (No haga que se rompa todas las excepciones detectadas - estará pegando "reanudar" interminablemente.)

En lo que respecta al "retraso" del registro, si el depurador deja que el programa continúe ejecutándose hasta el registro sucedió, no podrías depurar en el punto del lanzamiento.

Answer 5

Durante semanas después de iniciar el desarrollo de Android, me sentí frustrado por la falta de información que encontré en la ventana de LogCat. Ponía mensajes de registro en mi aplicación y nunca los veía, y sabía que mi aplicación arrojaba excepciones, pero nunca los vi.

Finalmente, un día lo descubrí: mi ventana LogCat mostraba el dispositivo equivocado. Normalmente tengo dos o tres dispositivos Android conectados a mi computadora en un momento dado, y LogCat muestra uno de esos otros dispositivos. Para cambiar esto, debe mostrar la ventana Dispositivos y seleccionar el dispositivo que desea en esa ventana.

Encuentro que este es un ejemplo de IU ridículamente mala. Aquí estoy mirando una ventana de LogCat y en ninguna parte de esa ventana hay ninguna indicación sobre qué registros de dispositivos estoy mirando. Tengo que saber lo suficiente como para abrir una ventana totalmente diferente y seleccionar el dispositivo allí. Literalmente perdí semanas de tiempo antes de darme cuenta de esto. Uno pensaría que LogCat usaría de forma predeterminada todos los dispositivos, o al menos, cambiaría automáticamente al dispositivo en el que más recientemente se lanzó una aplicación, pero no es así. Si te golpeas la cabeza contra el escritorio preguntándote por qué LogCat es tan inútil, quizás sea por eso.