Un dato incorrecto no debería cerrar una aplicación sin explicación. Tampoco debería convertirse en un resultado aparentemente válido. Vas a practicar cómo comunicar fallos con excepciones y dónde transformarlos en mensajes. La clave consiste en capturar solo los problemas que sabes interpretar y conservar la información necesaria para corregirlos.
Separar tres clases de situación
Una cantidad escrita como «tres» es una entrada no admitida. Un archivo que no existe es un problema de acceso o de ruta. Una variable mal escrita en tu código es un fallo de programación. Aunque los tres casos pueden detener la ejecución no conviene tratarlos como si fueran lo mismo. Cada uno necesita una respuesta diferente.
Las funciones de reglas lanzarán ValueError cuando una entrada incumpla el formato elegido. Las operaciones de archivos pueden producir excepciones derivadas de OSError. Un NameError suele indicar que debes revisar el código. Si capturas cualquier Exception y muestras «dato incorrecto» estarás ocultando ese tercer caso bajo un mensaje engañoso.
Mantener pequeño el bloque protegido
Un bloque try demasiado grande dificulta saber qué instrucción provocó el error. Coloca dentro la operación que esperas que falle y captura el tipo concreto. El resto del programa puede quedar fuera. Así un defecto inesperado conserva su rastro de ejecución en lugar de confundirse con una situación prevista.
def leer_cantidad(texto):
try:
cantidad = int(texto)
except ValueError as error:
raise ValueError("Escribe una cantidad entera") from error
if cantidad < 0:
raise ValueError("La cantidad no puede ser negativa")try: unidades = leer_cantidad("tres") except ValueError as error: print("No se ha registrado:", error) «`
La función no imprime. Comunica el motivo y deja que quien la llama decida la presentación. La expresión from error conserva la causa original. Cuando depures podrás ver tanto el fallo de conversión como el mensaje adaptado. Para una persona que utiliza la aplicación mostrarás solo la explicación pertinente en la capa exterior.
No utilizar un valor válido como señal de fallo
Si una función devuelve cero cuando falla no podrás distinguir el error de un artículo realmente agotado. Devolver una lista vacía cuando un archivo está dañado produce una confusión parecida: el programa puede creer que no había registros y sustituir el archivo. En nuestro proyecto un error de lectura detendrá la importación antes de guardar.
Tampoco conviertas una cantidad negativa en positiva con abs para que el programa continúe. Estarías cambiando la intención de la entrada. La validación debe rechazar lo que no admite o aplicar una transformación previamente definida. Hacer desaparecer el síntoma no equivale a resolver la causa y puede dejar datos imposibles de reconstruir.
Elegir la frontera del mensaje
Una función reutilizable no sabe si se utilizará desde la terminal o desde otro programa. Por eso no debe decidir siempre cómo hablar con una persona. app.py será nuestra frontera: recogerá argumentos, llamará a las operaciones y convertirá errores esperados en mensajes breves. Los módulos interiores conservarán el detalle técnico necesario para las pruebas.
Un mensaje útil dice qué operación no se completó y qué dato revisar. «No se pudo importar: registro 4, cantidad negativa» ayuda más que «Error». Evita afirmar que no se guardó nada si tu operación puede haber realizado escrituras parciales. Más adelante usaremos transacciones para poder sostener esa afirmación en la importación del inventario.
Leer el rastro de ejecución
Cuando aparece un error inesperado empieza por la última línea para identificar su tipo y mensaje. Después localiza la última referencia a un archivo que hayas escrito. Examina la operación y los valores implicados. No cambies cinco líneas al azar. Reproduce el fallo con la entrada más pequeña que puedas y modifica una sola causa plausible.
Guarda en el cuaderno la entrada, el resultado esperado y el mensaje real. Si pides ayuda comparte ese ejemplo reducido sin datos sensibles. Una captura de una ventana entera suele aportar menos que unas pocas líneas reproducibles. La depuración consiste en reunir evidencia que permita descartar explicaciones, no en probar cambios por intuición indefinidamente.
Recursos que deben cerrarse
Abrir un archivo y olvidarse de cerrarlo puede bloquear operaciones posteriores o dejar escrituras pendientes. Utiliza with para gestionar archivos. El cierre se realiza también cuando aparece una excepción dentro del bloque. No uses finally para repetir manualmente lo que un gestor de contexto resuelve con más claridad.
El significado de with depende del objeto. En SQLite el contexto de una conexión controla la confirmación o reversión de una transacción pero no cierra por sí mismo la conexión. Esta diferencia aparecerá expresamente en el capítulo de base de datos. No generalices el comportamiento de los archivos a cualquier objeto que acepte with.
Errores habituales
Un except vacío con pass hace desaparecer información. Atrapar KeyboardInterrupt impide además que la persona detenga el programa de la forma habitual. Aquí no lo haremos. Otro fallo es capturar un tipo demasiado amplio porque todavía no has identificado qué operación falla. Primero reproduce el problema y después elige qué excepción debes gestionar.
El error contrario consiste en mostrar un rastro técnico completo para una entrada corriente. Durante el desarrollo ese rastro ayuda pero la aplicación final debe explicar los fallos previstos. Mantén ambas necesidades separadas: mensajes comprensibles para situaciones conocidas y errores visibles para defectos que todavía necesitas reparar.
Lo que deberías recordar
- Captura excepciones concretas.
- Cero no debe representar un error.
- Las reglas comunican y la interfaz presenta.
- Un fallo inesperado debe conservar información para depurarlo.
Ejercicio práctico
Prueba leer_cantidad con «3», «0», «-2» y «tres». Anota qué casos devuelven un entero y cuáles comunican ValueError. Añade «2.5» y explica por qué una cantidad de unidades completas no admite esa escritura aunque represente un número.
Escribe una pequeña función exterior que llame a leer_cantidad y muestre el mensaje de error. Después introduce de forma temporal una variable mal escrita fuera del bloque try. Comprueba que el fallo de programación no se convierte en «cantidad incorrecta». Retira ese defecto una vez entendido el resultado.
Diseña un mensaje para un archivo ausente y otro para un registro CSV inválido. En cada caso indica una acción concreta que la persona pueda realizar. No prometas recuperación automática ni guardado seguro si todavía no has implementado esos mecanismos. Conserva los mensajes para revisarlos cuando construyas la interfaz final.
Siguiente: Convertir las comprobaciones en pruebas.
