Depuración y lectura de errores
Tipos de fallos
- Errores de sintaxis: el código no es legible para el intérprete.
- Errores en tiempo de ejecución (excepciones): algo imposible ocurre al correr.
- Bugs lógicos: corre sin avisar pero da resultados equivocados, los más difíciles.
El mensaje de excepción
Una excepción nombra su tipo (que indica la familia del problema), describe la causa concreta y, en la traza, muestra la pila de llamadas que la provocó. Empezar por el tipo ordena la búsqueda.
Leer una traza
- Se lee de abajo arriba: la última línea marca dónde ocurrió el fallo.
- Las líneas previas muestran desde qué llamada se llegó ahí.
- Buscar el primer fotograma propio descarta el ruido de librerías.
Errores que se repiten
- Indexar fuera de rango: la posición pedida no existe.
- Dividir entre cero: el denominador resultó cero.
- Atributo o clave ausente: se asumió algo que no estaba.
El método científico de depurar
Formular una hipótesis sobre la causa, diseñar una prueba barata que la refute o confirme, y actuar en consecuencia. Cambiar a ciegas, sin hipótesis, es el camino más largo.
Reducir el caso
- Aislar el fallo en el ejemplo más pequeño que lo reproduce.
- Al reducir superficie, la causa salta a la vista.
- El caso mínimo, además, prueba que lo arreglaste.
Observar el estado
Imprimir variables, usar un depurador con puntos de interrupción o inspeccionar el paso a paso son maneras de ver qué valor tenía cada cosa en el instante exacto, sin adivinar.
Aislar por mitades
- Comprobar el punto medio: ¿el valor ya es erróneo ahí?
- Recorta el territorio sospechoso a la mitad cada vez.
- Con pocos pasos localizas la instrucción culpable.
Capturar excepciones
Un bloque que intenta, y ante cierto tipo de error reacciona, permite que el programa maneje lo esperable sin romperse. Capturar demasiado amplio, en cambio, oculta fallos reales.
Registrar para no repetir
- Anotar causa y arreglo de cada bug convierte la memoria en activo del equipo.
- Un historial de errores revela suposiciones frágiles del diseño.
- Buena parte de los bugs nuevos son primos de otros ya vistos.
Probar para confiar
Una prueba que reproduce el bug, falla antes del arreglo y pasa después, es la garantía de que el problema quedó resuelto y de que no volverá en silencio.
Ejemplo resuelto: un índice fuera de rango ajeno
Tu programa falla con índice fuera de rango dentro de una función de librería que llamaste tú. Con la traza se decide dónde está la culpa.
- Leer la traza de abajo arriba hasta la última línea, que indica el punto exacto del fallo.
- Subir hasta el primer fotograma propio: ahí está la llamada que lanzaste.
- Inspeccionar el argumento que pasaste en esa línea imprimiendo su valor real.
- Reducir el caso al ejemplo más pequeño que reproduce el error.
- Corregir la suposición falsa (una posición inexistente) y verificar que el caso ya pasa.
¿Para qué sirve en la realidad?
Depurar con método —leer la traza, formular hipótesis y aislar el caso mínimo— convierte horas de cambios a ciegas en minutos, y es una de las habilidades que más tiempo ahorra en cualquier proyecto de software o datos.
En una traza de error, para localizar dónde se produjo el fallo conviene mirar:
Un bug lógico es el tipo de error más difícil de detectar porque el programa corre sin lanzar excepción.
Depuración
Ordena las etapas del método sistemático de depuración:
Reproducir
Hipótesis
Observar
Arreglar
Probar
Depuración
Proceso de encontrar y corregir defectos de software.
Une cada tipo de fallo con su señal:
Leer errores con método
# Depuración ## Tipos ### sintaxis ### excepción ### lógico ## Traza ### se lee de abajo arriba ### buscar el fotograma propio ## Método ### hipótesis ### reducir el caso ### observar y probar
Traza de pila
Registro del recorrido de llamadas que ayuda a localizar un error.
Tu programa lanza un índice fuera de rango en una función que no escribiste tú, llamada desde la tuya. Explica paso a paso cómo usarías la traza para decidir si el problema es tuyo o del argumento que pasaste.