Quiero agregar que un depurador no siempre es la solución perfecta y no siempre debería ser la solución de referencia para la depuración. A continuación, se muestran algunos casos en los que un depurador podría no funcionar para usted:
- La parte de su programa que falla es realmente grande (¿pobre modularización, tal vez?) Y no está exactamente seguro de dónde comenzar a recorrer el código. Pasar por todo esto puede llevar demasiado tiempo.
- Su programa utiliza muchas devoluciones de llamada y otros métodos de control de flujo no lineales, lo que confunde al depurador cuando lo recorre.
- Su programa tiene varios subprocesos. O peor aún, su problema es causado por una condición de carrera.
- El código que tiene el error se ejecuta muchas veces antes de que falle. Esto puede ser particularmente problemático en los bucles principales o, peor aún, en los motores de física, donde el problema podría ser numérico. Incluso establecer un punto de interrupción, en este caso, simplemente haría que lo golpeara muchas veces, sin que apareciera el error.
- Su programa debe ejecutarse en tiempo real. Este es un gran problema para los programas que se conectan a la red. Si configura un punto de interrupción en su código de red, el otro extremo no va a esperar a que lo pase, simplemente se agotará. Los programas que dependen del reloj del sistema, por ejemplo, juegos con frameskip, tampoco están mucho mejor.
- Su programa realiza algún tipo de acciones destructivas, como escribir en archivos o enviar correos electrónicos, y le gustaría limitar la cantidad de veces que necesita ejecutarlo.
- Puede decir que su error es causado por valores incorrectos que llegan a la función X, pero no sabe de dónde provienen estos valores. Tener que ejecutar el programa una y otra vez, establecer puntos de interrupción cada vez más atrás, puede ser una gran molestia. Especialmente si se llama a la función X desde muchos lugares del programa.
En todos estos casos, hacer que su programa se detenga abruptamente podría hacer que los resultados finales difieran, o pasar manualmente en busca de la línea donde se produjo el error es demasiado complicado. Esto también puede suceder si su error es un comportamiento incorrecto o un bloqueo. Por ejemplo, si la corrupción de la memoria provoca un bloqueo, cuando ocurre el bloqueo, está demasiado lejos de donde ocurrió la corrupción de la memoria por primera vez y no queda información útil.
¿Entonces cuales son las alternativas?
Lo más simple es simplemente registro y afirmaciones. Agregue registros a su programa en varios puntos y compare lo que obtiene con lo que espera. Por ejemplo, vea si la función en la que cree que hay un error se llama en primer lugar. Vea si las variables al comienzo de un método son las que cree que son. A diferencia de los puntos de interrupción, está bien que haya muchas líneas de registro en las que no ocurra nada especial. Puede simplemente buscar en el registro después. Una vez que llegue a una línea de registro que sea diferente de lo que espera, agregue más en la misma área. Reducirlo cada vez más, hasta que sea lo suficientemente pequeño como para poder registrar cada línea en el área con errores.
Las afirmaciones se pueden usar para atrapar valores incorrectos a medida que ocurren, en lugar de una vez que tienen un efecto visible para el usuario final. Cuanto más rápido detecte un valor incorrecto, más cerca estará de la línea que lo produjo.
Refactorización y prueba unitaria. Si su programa es demasiado grande, valdría la pena probarlo una clase o una función a la vez. Déle entradas y observe las salidas, y vea cuáles no son las que espera. Ser capaz de reducir un error de un programa completo a una sola función puede marcar una gran diferencia en el tiempo de depuración.
En caso de pérdidas de memoria o pisadas de memoria, utilice las herramientas adecuadas que puedan analizarlas y detectarlas en tiempo de ejecución. Ser capaz de detectar dónde se produce la corrupción real es el primer paso. Después de esto, puede usar los registros para volver al lugar donde se introdujeron los valores incorrectos.
Recuerde que la depuración es un proceso que retrocede. Tiene el resultado final, un error, y encuentra la causa que lo precedió. Se trata de trabajar hacia atrás y, desafortunadamente, los depuradores solo dan un paso adelante. Aquí es donde un buen registro y análisis post mortem pueden brindarle resultados mucho mejores.