Con la v0.18 el paquete tareafacil/ se entiende: tiene docstrings, anotaciones de tipo y un README. Pero sigue siendo frágil. Si Marta abre el tareas.json con un editor y se deja una coma de más, el programa muere con un traceback antes de mostrar el menú. Si Luis escribe «tres» cuando se le piden los días, muere igual. Y todo lo que hubiera en memoria se pierde. Esta lección cierra por fin la promesa que el curso arrastra desde Conversión de tipos y validación y desde Guardar datos en archivos: capturar los errores con try/except en lugar de rezar para que no ocurran. Aprenderás a distinguir los tres tipos de error, a leer un traceback sin miedo, a decidir qué se captura y qué se deja subir, a lanzar excepciones propias como TareaInvalida, a registrar lo que pasa con logging en vez de con print y a depurar con puntos de interrupción en lugar de adivinar. Al final, TareaFácil dejará de romperse.

1. Los tres tipos de error
2. Leer un traceback
3. Catálogo de excepciones habituales
4. try/except: capturar lo que se debe capturar
5. else y finally: el flujo completo
6. raise y excepciones propias
7. La política de errores: EAFP frente a LBYL
8. logging frente a print
9. Depurar de verdad: método, VS Code y pdb
10. TareaFácil v0.19: el programa que no se rompe
11. Errores comunes y consejos
12. Ejercicios
13. Conclusión

No todos los fallos son iguales, y cada uno se caza de una manera distinta; distinguirlos es el primer paso para no perder el tiempo buscando donde no hay nada. El tercero es el peligroso: los dos primeros avisan a gritos, pero el error de lógica se queda callado, imprime «progreso: 0.6 %» y nadie se da cuenta hasta que Marta pregunta por qué la tarea del cartel lleva tres semanas al 0,6 %. Contra ese no hay try/except que valga: hacen falta el método de depuración del apartado 9 y las pruebas de Pruebas automatizadas.

Cuando salta una excepción, Python imprime un traceback: el mapa de cómo se llegó hasta el fallo. Se lee de una forma muy concreta: de abajo arriba para saber qué pasó, y de arriba abajo para saber por qué.

Ese bloque contiene toda la información que necesitas:

• most recent call last: las llamadas están en orden —arriba la primera, abajo la que ha estallado—; eso es la pila de llamadas. Y la última línea dice qué ha pasado: el tipo (JSONDecodeError) y el mensaje (falta una coma en la línea 8 del fichero de datos).
• La línea culpable de tu código es la última que pertenece a tu proyecto, aquí almacen.py, line 41. Lo de debajo es la biblioteca estándar: json no falla, solo es donde se manifiesta.
• El origen real suele estar más arriba: cargar() funciona bien; el problema es el fichero que se le ha dado. Recorre la pila hacia arriba preguntándote «¿quién le pasó este dato?»; en el 90 % de los casos el error está ahí.

Estas son las que te vas a encontrar una y otra vez; reconocerlas de un vistazo ahorra muchísimo tiempo:

La sintaxis es simple: en el bloque try va el código que puede fallar; en el except, qué hacer si falla.

Sin el try, un «tres» tumbaba el programa. Con él, el usuario recibe un mensaje comprensible y la aplicación sigue viva. Ahora bien, hay dos formas de escribirlo mal:

except: a secas captura hasta un KeyboardInterrupt (el Ctrl+C con el que el usuario intenta salir) y un SystemExit, así que tu programa se vuelve imposible de interrumpir. except Exception no llega tan lejos, pero sigue tapando errores de programación —un nombre mal escrito, un AttributeError— y convierte un fallo evidente en un comportamiento raro imposible de diagnosticar. La regla es: captura la excepción concreta que sabes que puede ocurrir y que sabes cómo manejar; lo demás debe subir y hacer ruido. Cuando hay varias posibilidades se encadenan except o se agrupan en una tupla, y con as se recoge el objeto para leer su mensaje:

Los except se comprueban en orden y solo se ejecuta el primero que encaje: por eso las excepciones concretas van siempre antes que las generales.

El bloque try admite dos cláusulas más que redondean la estructura. else se ejecuta solo si no hubo excepción, lo que permite dejar en el try únicamente la línea peligrosa; finally se ejecuta siempre, haya fallado o no, incluso si el try hace return, y es el sitio de la limpieza.

Fíjate en la rama de la derecha: si ningún except encaja, el finally se ejecuta igualmente y después la excepción continúa subiendo. Esa es la clave del diseño: finally garantiza la limpieza sin tragarse el error. Para los ficheros, eso ya lo resuelve algo que usas desde 05-05: with cierra el fichero automáticamente y hace innecesario el finally en ese caso.

Hasta ahora las excepciones venían de Python. También puedes lanzarlas tú, y es lo correcto cuando tu función recibe algo con lo que no puede trabajar: fallar pronto y con un mensaje claro es mejor que devolver un valor inventado.

Un raise a secas dentro de un except relanza la excepción original con su traceback intacto, que es lo que quieres cuando solo necesitas anotar algo de paso. Y cuando conviertes un error de bajo nivel en otro más significativo, encadénalos con raise ... from: raise TareaInvalida("prioridad desconocida") from error conserva la causa en el traceback. Definir una excepción propia es sorprendentemente simple, una clase vacía que hereda de otra excepción:

¿Por qué heredar de ValueError y no de Exception? Porque así el código antiguo sigue funcionando: quien capturaba ValueError para validar entradas seguirá capturando también las tuyas. Recuerda además que todas las excepciones descienden de Exception, y que esa jerarquía manda: except ValueError no atrapa un KeyError, pero except Exception los atrapa todos, incluidos los que no esperabas. Una jerarquía propia da precisión al capturar (except TareaInvalida atrapa cualquier problema de datos de tarea, incluida PrioridadInvalida, sin tocar un ValueError de otra parte), mensajes del dominio en lugar de mensajes sobre conversiones de texto, y un único sitio que documenta las reglas del negocio. La convención es agruparlas en el módulo del dominio —en TareaFácil, modelo.py— con nombres reconocibles (...Invalida, ...Error).

Toda aplicación necesita una política: qué se captura y qué se deja subir. La regla es fácil de recordar: captura un error solo si puedes hacer algo útil con él —pedir el dato otra vez, usar un valor por defecto, avisar al usuario—. Si no puedes, déjalo subir: un fallo visible es infinitamente mejor que uno silencioso. Para validar hay además dos estilos, y Python tiene preferencia por uno:

Python prefiere EAFP, y con ficheros es objetivamente más seguro: entre el exists() y el open() pasa un instante en el que otro programa puede borrar o mover el fichero. Aquella comprobación con Path.exists() de 05-05 era correcta para lo que sabíamos entonces; esta es la versión robusta que prometimos.

Cuando algo falla, la tentación es sembrar el código de print("aqui llego"). Funciona para salir del paso, pero en un programa real es un mal sistema: hay que borrarlos después (y siempre se olvida alguno), se mezclan con la salida legítima y no dejan constancia de nada. El módulo logging de la biblioteca estándar resuelve las tres cosas.

Tres detalles marcan la diferencia. level decide qué se registra: subiéndolo a WARNING silencias los mensajes de detalle sin tocar una línea de código. filename manda todo a un fichero, así que mañana puedes ver qué ocurrió sin haber estado delante. Y logging.exception(), usado dentro de un except, escribe el mensaje y el traceback entero: es la forma correcta de registrar un fallo que has capturado y no quieres perder.

Depurar no es mirar el código fijamente hasta que confiese. Es un método de cuatro pasos:

1. Reproducir: encontrar la secuencia exacta que provoca el fallo, siempre. Un error que no sabes reproducir no lo puedes arreglar.
2. Aislar: reducir el caso al mínimo. ¿Falla con una tarea o hacen falta veinte? ¿Con cualquier prioridad?
3. Formular una hipótesis concreta («creo que dias llega como texto desde el JSON») y comprobarla: una sola cosa cada vez; si es falsa, se descarta y se formula otra.

Para ese último paso está el depurador. En VS Code haces clic a la izquierda del número de línea para poner un punto de interrupción (un círculo rojo), arrancas con F5 y el programa se detiene justo antes de ejecutar esa línea; ahí puedes inspeccionar las variables en el panel lateral, ver la pila de llamadas y avanzar con F10 (ejecuta la línea entera), F11 (entra en la función) y F5 (continúa). Sin editor gráfico, escribe breakpoint() en la línea que te interese y ejecuta: se abrirá una consola (Pdb) en ese punto.

Y una última herramienta, en dos líneas: assert condicion, "mensaje" lanza un AssertionError si la condición es falsa. Sirve para comprobar suposiciones internas mientras desarrollas, pero no para validar datos del usuario, porque Python puede desactivar los assert con la opción -O. Su sitio natural son las pruebas, y ahí lo retomamos en 08-04.

Primero, almacen.py sobrevive a que el JSON no exista o esté corrupto:

Fíjate en la decisión de diseño: ante un fichero corrupto no se borra nada, se aparta con otro nombre y se sigue, así que el usuario no pierde sus datos. Segundo, el modelo valida y lanza su propia excepción, y la interfaz la captura para volver a preguntar:

Y en __main__.py, la configuración del registro y una red de seguridad final para que ningún fallo inesperado se lleve por delante los datos:

TareaFácil v0.19: un JSON corrupto ya no tumba el programa, una prioridad inventada se rechaza con un mensaje del dominio, un dias de texto se convierte o se rechaza con claridad, un Ctrl+C guarda antes de salir y todo queda registrado en tareafacil.log.

• Usar except: o except Exception por comodidad, o capturar y no hacer nada (except ValueError: pass). Ocultan errores de programación y crean fallos invisibles: captura la excepción concreta, y si no puedes hacer nada útil con ella, déjala subir.
• Poner el except general antes que los concretos, o meter medio programa dentro del try. Se comprueban en orden, así que el primero que encaje gana; y en el try debe ir solo la línea que puede fallar, con el resto en el else.
• Leer el traceback por encima, o depurar con print en un programa real. La última línea dice qué pasó y la última línea tuya dice dónde; y para lo demás está logging, que se filtra por nivel, va a un fichero y no hay que borrarlo después.
• Consejo: escribe el mensaje pensando en quien lo va a leer. «Prioridad no valida: 'urgente'. Usa alta, media o baja» vale mil veces más que «error de validación».

Explica qué ha pasado, en qué línea de código propio está el problema y cómo lo arreglarías:

Reescribe esta función para que sobreviva a un fichero inexistente, a una línea mal formada y a un valor no numérico, registrando cada problema con logging y devolviendo lo que sí se haya podido leer:

Define una excepción PresupuestoInvalido para el Estudio Alba y una función validar_presupuesto(importe, cliente) que la lance si el importe no es un número, si es negativo o si supera los 50.000 € (límite que exige la aprobación de Marta). Escribe después el try/except que la usa mostrando un mensaje distinto en cada caso.

Solución 1.

La última línea dice qué: una división por cero. La última línea de código propio dice dónde: informes.py, line 15, en media_dias. Como sum(...) no divide, el cero solo puede ser len(tareas): la lista de tareas está vacía. El error real, sin embargo, no está en la línea 15 sino en quien llamó desde la línea 20 con una lista vacía; la función solo lo ha manifestado.

Si una lista vacía fuera un caso imposible —un error de programación en quien llama—, lo correcto sería lo contrario: no capturarlo y dejar que el ZeroDivisionError haga ruido.

Solución 2.

Dos ideas importantes. El try interior envuelve solo las dos líneas que pueden fallar, y captura ValueError porque tanto un split que no devuelve dos partes como un int("ocho") lanzan esa misma excepción. Y el fallo de una línea no aborta el fichero entero: se registra con su número y el bucle continúa. Esa es la diferencia entre un programa frágil y uno robusto: sigue haciendo todo lo que sí puede hacer.

Solución 3.

Fíjate en el from error de la primera conversión: conserva la causa original en el traceback, de modo que quien depure sabrá que detrás de PresupuestoInvalido había un ValueError de float(). Los tres mensajes son distintos y dicen qué hacer, que es la marca de un buen error. Y el else deja claro que la línea de éxito solo se ejecuta si no hubo excepción.

Los errores son de tres tipos: los de sintaxis impiden ejecutar, los de ejecución lanzan excepciones y los de lógica no avisan de nada y solo se cazan depurando y probando. Ante una excepción, el traceback lo cuenta todo: la última línea dice qué ha pasado, la última línea de código propio dice dónde, y el origen real suele estar más arriba en la pila. Reconocer el catálogo habitual —ValueError, TypeError, KeyError, IndexError, FileNotFoundError, ZeroDivisionError, AttributeError, json.JSONDecodeError— ahorra la mitad del trabajo. Con try/except se captura la excepción concreta que sabes manejar, nunca except: a secas ni except Exception, colocando los casos concretos antes que los generales, agrupando varios en una tupla y recogiendo el objeto con as error; else ejecuta lo que solo tiene sentido si no hubo fallo y finally garantiza la limpieza pase lo que pase, incluso cuando la excepción sigue subiendo. Con raise lanzas errores a propósito para fallar pronto y con un mensaje claro, raise a secas relanza sin perder el traceback y raise ... from conserva la causa. Una excepción propia como TareaInvalida, heredada de ValueError, aporta precisión al capturar y mensajes del dominio. La política se resume en una frase: captura solo lo que puedas resolver y deja subir el resto, prefiriendo EAFP a LBYL cuando hay ficheros de por medio. Para saber qué está pasando, logging sustituye al print con sus cinco niveles, su salida a fichero y su logging.exception(). Y para los errores de lógica, el método —reproducir, aislar, formular hipótesis, comprobar— junto con los puntos de interrupción de VS Code y breakpoint()/pdb.

TareaFácil es ahora la v0.19: un tareas.json corrupto se aparta con una copia en lugar de tumbar el programa, una prioridad inventada se rechaza con TareaInvalida y la interfaz vuelve a preguntar, un dias que llega como texto se convierte o se explica, un Ctrl+C guarda antes de salir y todo queda anotado en tareafacil.log. El programa aguanta. Pero fíjate en lo que acabas de hacer: has cambiado almacen.py, modelo.py, interfaz.py y __main__.py a la vez, y no hay forma de volver atrás si algo de esto ha empeorado otra cosa. No existe una copia del estado anterior, ni un registro de qué se tocó ni por qué. Eso se acaba en Control de versiones: Git, el historial del proyecto, y la tranquilidad de poder experimentar sabiendo que nada se pierde.