En la lección anterior aprendimos a leer el aviso; en esta aprendemos a hacernos cargo de él. La herramienta es la estructura try/except, y con ella Papyrus va a saldar hoy tres deudas concretas: cargar_catalogo() dejará de morir cuando catalogo.json no exista (adiós al paliativo Path.exists()), el peaje str→float del CSV dejará de "rezar para que traiga números" y sobrevivirá a filas corruptas, y el int(input()) que arrastra su ValueError desde el módulo 1 — parcheado en el módulo 2 con isdigit() — recibirá por fin su validación definitiva. Por el camino veremos las cuatro piezas de la estructura completa (try, except, else, finally), cómo capturar el objeto excepción con as e, y una tabla de antipatrones encabezada por el peor de todos: el except: pelado.

1. La estructura try/except: pedir perdón, por fin
2. Capturar tipos concretos (y por qué nunca except: pelado)
3. Varios except y capturar el objeto con as e
4. Las piezas restantes: else y finally
5. Papyrus, versión robusta: cargar_catalogo() y el CSV de ventas
6. Saldar la deuda del módulo 1: pedir_entero()

La sintaxis mínima tiene dos bloques: lo que intentas y lo que haces si falla:

Cómo fluye la ejecución, paso a paso:

1. Python ejecuta el bloque try línea a línea.
2. Si no salta ninguna excepción, el bloque except se ignora por completo y la vida sigue.
3. Si una línea del try lanza una excepción, la ejecución abandona el try inmediatamente (las líneas restantes del bloque no se ejecutan) y Python busca un except cuyo tipo coincida.
4. Coincidir significa: la excepción es de esa clase o de una subclase — la jerarquía de 07-01 en acción. Un except LookupError: atrapa tanto KeyError como IndexError.
5. Si ningún except coincide, la excepción sigue propagándose hacia arriba, como si el try no existiera.

El punto 5 es importante: try no es un escudo mágico. Solo atrapa lo que le dices que atrape. Y eso es una virtud, como vamos a ver ahora mismo.

La tentación del principiante es "que no falle nada": envolverlo todo y atraparlo todo. Es el error más caro de todo el módulo, porque convierte errores ruidosos en errores silenciosos — y un error silencioso puede costarle dinero a Ana sin que nadie se entere.

¿Qué esconde ese except: pelado? Todo. Si hay una errata catalgo dentro de cargar_catalogo() (un NameError, un bug tuyo), el programa arranca con catálogo vacío y nadie sabrá jamás por qué. Si Ana pulsa Ctrl+C para cancelar (KeyboardInterrupt, que hereda de BaseException y también cae en un except: pelado), el programa lo ignora. El traceback — ese informe forense gratuito de 07-01 — va directo a la basura.

La regla que resume la tabla: captura solo lo que esperas y sabes manejar; deja que todo lo demás explote. Una excepción no manejada con su traceback es infinitamente mejor que un programa que miente.

Un mismo try puede fallar de formas distintas que merecen reacciones distintas. Se encadenan varios except, y Python usa el primero que coincida (por eso los tipos específicos van antes que los genéricos):

Dos novedades aquí:

• as e guarda el objeto excepción en la variable e, disponible dentro del bloque. Recuerda de 07-01 que la excepción es un objeto: print(e) muestra su mensaje, y algunos tipos llevan atributos extra (e.lineno en JSONDecodeError dice en qué línea del JSON está el destrozo). La variable solo existe dentro de su bloque except.
• json.JSONDecodeError es la respuesta a otra pregunta del cierre de M6: "¿y si la copia está corrupta?". Si alguien editó mal catalogo.json a mano — el módulo 6 solo pudo suplicar "no edites mal el JSON" —, json.load() lanza esta excepción, y ahora sabemos distinguir archivo ausente (recuperable: catálogo vacío) de archivo corrupto (no inventes datos: avisa y detente).

Si varias excepciones merecen la misma reacción, se agrupan en una tupla: except (ValueError, KeyError) as e:.

La estructura completa tiene cuatro bloques, cada uno con un papel preciso:

¿Por qué molestarse con else en vez de escribirlo todo dentro del try? Precisión: si f.read() estuviera dentro del try y fallara por otro motivo, un except demasiado amplio podría atraparlo y diagnosticar mal. El try debe abrigar solo las líneas cuyo fallo sabes manejar; else recoge la continuación del camino feliz.

¿Y finally? Te sonará la garantía: es exactamente lo que el with del módulo 6 hace por ti con los archivos — cerrar pase lo que pase. De hecho, with está construido sobre esta mecánica, y en el módulo 8 aprenderemos a fabricar nuestros propios context managers. Mientras tanto, la pareja práctica es: with para archivos, finally para cualquier otra limpieza que deba ocurrir sí o sí (imprimir un resumen de cierre, restaurar un estado).

Hora de pagar las deudas del módulo 6. Así quedó cargar_catalogo() entonces, paliativo incluido:

Y así queda la versión EAFP, que además distingue ausente de corrupto:

Punto por punto:

• El try cubre solo la apertura y el parseo — las dos operaciones que pueden fallar de estas formas. La construcción del diccionario queda fuera: si Libro(**l) fallara (un precio negativo en el JSON dispararía el ValueError del __post_init__ de M5), queremos ver ese traceback, no confundirlo con un problema de archivo.
• FileNotFoundError es un caso esperado y recuperable: primer arranque en un ordenador nuevo. Catálogo vacío + aviso honesto. Sin condición de carrera: el open() es la comprobación.
• JSONDecodeError es esperado pero no recuperable en silencio: inventar un catálogo vacío cuando existe uno corrupto haría que Ana machacara sus datos reales al guardar. Avisamos con el detalle del error y paramos. Manejar bien una excepción a veces significa detenerse mejor, no continuar a cualquier precio.

Segunda deuda: el peaje str→float de ventas.csv (06-02). Si una fila trae "gratis" como importe, la versión M6 muere en plena suma. La M7 salta la fila corrupta, cuenta los errores y sigue:

Observa el try anidado y mínimo: el interior abriga una sola línea (la conversión) y atrapa un solo tipo (ValueError). Una fila mala ya no tumba el cierre del día — pero tampoco desaparece: se cuenta y se muestra, porque silenciarla sería el antipatrón pass de la tabla. El else interior suma la venta al contador solo cuando la conversión fue bien: exactamente el papel que le asignamos a else.

La deuda más antigua del curso. En el módulo 1, int(input()) explotaba si Júlia tecleaba "tres". En el módulo 2 lo parcheamos con while True + isdigit(), y ya entonces avisamos de que era provisional. ¿Por qué? Porque isdigit() intenta predecir lo que int() aceptará, y predice mal: "-2".isdigit() es False (rechaza negativos legítimos), " 4 ".isdigit() es False (rechaza espacios que int() tolera). Es LBYL con un validador que no coincide con el conversor. La solución EAFP: que decida el propio int().

• El return dentro del try rompe el bucle en cuanto hay un entero válido — no hace falta break.
• Si int() lanza ValueError, el except informa (mostrando lo que se tecleó, mensaje accionable) y el while True reintenta.
• El juez es int() mismo: acepta "-2" y " 4 ", rechaza "tres" y "4.5". Cero desacuerdos entre validador y conversor, porque son la misma cosa.

La misma plantilla sirve para pedir_precio() con float(): guárdala, porque es de las funciones más reutilizadas que escribirás.

• except: pelado. El antipatrón número uno. Atrapa hasta el Ctrl+C de Ana y entierra tus propios bugs. Siempre un tipo concreto.
• try kilométrico. Si el bloque tiene diez líneas, ya no sabes cuál falló ni si tu except es la reacción adecuada. Encoge el try hasta la línea culpable; usa else para la continuación.
• Silenciar con pass. except ValueError: pass hace desaparecer datos sin dejar rastro. En cierre_de_caja() las filas corruptas se cuentan y se muestran; en 07-05 irán al log.
• Ordenar mal los except. Python usa el primero que coincide: si pones except Exception: antes que except ValueError:, el segundo es código muerto. De lo específico a lo general.
• Olvidar que else existe. No es obligatorio, pero meter el camino feliz dentro del try "porque cabe" acaba atrapando excepciones que no querías atrapar.
• Consejo: antes de escribir un except, pregúntate: "¿qué voy a hacer con este error?". Si la respuesta es "nada", probablemente no debas atraparlo: deja que se propague hacia quien sí pueda hacer algo.
• Consejo: fíjate en que nuestros mensajes de aviso siempre incluyen el dato culpable ('{texto}', {fila!r}). Un aviso sin el dato obliga a adivinar; con el dato, se arregla en un minuto.

1. pedir_precio(). Escribe la gemela de pedir_entero(): pide un precio con float(), reintenta ante ValueError y, además, rechaza precios negativos con un mensaje distinto ("un precio no puede ser negativo") sin salir del bucle. Pruébala con "9,95" (coma decimal, muy típico en España): ¿qué ocurre y por qué?

2. cargar_config() a prueba de todo. El módulo 6 dejó config.json con {"nombre_tienda", "iva_libros", "descuento_socio"}. Escribe cargar_config() que: devuelva el diccionario si todo va bien; ante FileNotFoundError devuelva la configuración por defecto {"nombre_tienda": "Papyrus", "iva_libros": 0.04, "descuento_socio": 0.05} con un aviso; y ante json.JSONDecodeError muestre el error y relance SystemExit(1). Añade un finally que imprima siempre "Configuración: proceso terminado." y comprueba que aparece en los tres escenarios.

3. Cazar el antipatrón. Este código "funciona", pero comete al menos tres pecados de la tabla de antipatrones. Identifícalos y reescríbelo:

   def precio_socio(catalogo, titulo):
       try:
           libro = catalogo[titulo.strip().casefold()]
           precio = libro.precio * (1 - DESCUENTO_SOCIO)
           print("El precio para socios de " + titulo + " es " + str(round(precio, 2)))
           return precio
       except:
           return -1
   

1. def pedir_precio(mensaje):
       while True:
           texto = input(mensaje)
           try:
               precio = float(texto)
           except ValueError:
               print(f"'{texto}' no es un número. Usa punto decimal, p. ej. 9.95")
               continue
           if precio < 0:
               print("Un precio no puede ser negativo. Inténtalo de nuevo.")
               continue
           return precio
   

   Con "9,95" salta ValueError: float() solo entiende el punto decimal. Por eso el mensaje del except sugiere el formato correcto — mensaje accionable. (Alternativa amable: texto.replace(",", ".") antes de convertir.) Nota el orden: primero la conversión (EAFP), luego la validación del valor ya convertido (LBYL sobre un dato que ya tienes en la mano, legítimo según vimos en 07-01).

2. CONFIG_DEFECTO = {"nombre_tienda": "Papyrus", "iva_libros": 0.04, "descuento_socio": 0.05}
   
   def cargar_config():
       ruta = BASE / "datos" / "config.json"
       try:
           with open(ruta, encoding="utf-8") as f:
               return json.load(f)
       except FileNotFoundError:
           print("Aviso: sin config.json; se usan valores por defecto.")
           return dict(CONFIG_DEFECTO)
       except json.JSONDecodeError as e:
           print(f"config.json corrupto: {e}")
           raise SystemExit(1)
       finally:
           print("Configuración: proceso terminado.")
   

   El finally se imprime en los tres escenarios — incluso con los return de por medio e incluso cuando SystemExit está propagándose. Esa es su garantía. Detalle fino: se devuelve dict(CONFIG_DEFECTO) (una copia) para que nadie mute el diccionario por defecto compartido, recuerdo del aliasing del módulo 4.

3. Pecados: (1) except: pelado — atraparía hasta un NameError si DESCUENTO_SOCIO no estuviera definido, ocultando un bug; (2) try demasiado ancho — solo el acceso catalogo[...] puede fallar de forma esperable (KeyError); el print y la aritmética no deberían estar abrigados; (3) devolver -1 como error disfrazado de precio — quien reciba ese -1 podría cobrárselo a Júlia. Reescritura:

   def precio_socio(catalogo, titulo):
       try:
           libro = catalogo[titulo.strip().casefold()]
       except KeyError:
           print(f"'{titulo}' no está en el catálogo.")
           return None
       return round(libro.precio * (1 - DESCUENTO_SOCIO), 2)
   

   ¿Y es None la mejor señal de "no encontrado"? ¿O debería esta función lanzar su propia excepción? Esa pregunta exacta — cuándo devolver None y cuándo raise — abre la próxima lección.

Ya sabes pedir perdón con estilo: try mínimo alrededor de la línea que puede fallar, except de tipos concretos (jamás pelado), varios except ordenados de lo específico a lo general, as e para aprovechar el mensaje del objeto excepción, else para el camino feliz que depende del éxito y finally para la limpieza incondicional. Papyrus ha pagado tres deudas: cargar_catalogo() distingue "no hay catálogo" (recuperable) de "catálogo corrupto" (mejor parar), cierre_de_caja() sobrevive a filas ilegibles contándolas en vez de morir o silenciarlas, y pedir_entero() jubila al impostor isdigit() dejando que int() sea su propio juez. Hasta ahora solo hemos reaccionado a excepciones que Python lanza por su cuenta. La próxima lección invierte los papeles: aprenderás a lanzarlas tú con raise — decidir cuándo una situación merece excepción y cuándo un simple None, relanzar, encadenar con from, y proteger tus funciones con guard clauses. El raise ValueError que el __post_init__ de Libro hace desde el módulo 5 dejará de ser un acto de fe para convertirse en una decisión de diseño.