Manejo de errores de Python: intente / excepto / si no / finalmente en 2026
El manejo de errores separa el "código que funciona en su máquina" del "código que sobrevive a la producción". try/except de Python parece simple, pero la forma completa de cuatro palabras clave - try/except/else/final- codifica una sorprendente cantidad de estructura que la mayoría de los tutoriales omiten.
Esta guía cubre: qué significa realmente cada palabra clave, los seis patrones que verá en cada código base de backend, cuándo definir sus propias excepciones y los tres antipatrones que permiten que los errores pasen desapercibidos en sus pruebas.
Las cuatro palabras clave, precisamente
La cláusula "else" está infrautilizada. Dice "el siguiente bit depende de que el intento tenga éxito, pero no quiero que esté protegido por el mismo excepto". Es el lugar correcto para la continuación del camino feliz: colocarlo dentro de try accidentalmente detecta excepciones no relacionadas de ship(result).
Los seis patrones
1. Reintentar en caso de fallo transitorio
Regla: reintente SÓLO en caso de errores transitorios (red, tiempo de espera, 429, 503). Nunca vuelvas a intentarlo con ValueError, KeyError, TypeError; esos son errores de código y al volver a intentarlo solo se ejecuta el error tres veces.
2. Guardia con else
El "else" garantiza que el "archivo" se abrió correctamente Y la limpieza del ámbito se realiza con "con". Aviso: process() podría generar ValueError, que se propagará hacia arriba, NO será detectado por excepto FileNotFoundError.
3. Limpieza con finalmente (antes de que existiera con)
En el código moderno, usarías with db.connect() as conn: - with es el azúcar sobre try/final para el caso de limpieza común. Busque "finalmente" explícito solo cuando el recurso no admita el protocolo del administrador de contexto.
4. Volver a subir con contexto añadido
raise NewException(...) from e encadena la excepción original a la nueva para que el rastreo muestre AMBAS. Nunca escriba raise NewException(str(e)), eso descarta el rastreo original.
5. Capte la excepción más estrecha que pueda
Regla: cuanto más estrecha sea la excepción, mejor. Si no sabe qué "proceso" puede generar, ejecútelo y descúbralo. excepto Excepción: es un olor a código el 90% del tiempo.
6. "subir" dentro de "excepto" - volver a subir limpiamente
El simple "aumento" mantiene intacto el rastreo original. Nunca "levantar e" (Python 3 es inteligente al respecto, pero "levantar" es la forma idiomática).
Excepciones personalizadas: cuando vale la pena
Defina su propia clase de excepción cuando:
1. Las personas que llaman deben "excepto MyError:" específicamente (es decir, usted tiene una API invocable y los usuarios deben bifurcarse según el tipo de falla).
2. Su biblioteca/servicio genera múltiples errores relacionados que comparten contexto.
Ahora las personas que llaman pueden captar de forma amplia (excepto PaymentError) o de forma restringida (excepto CardDeclinedError). Los atributos estructurados en la excepción (e.card_last4) permiten a los controladores de errores crear una experiencia de usuario útil sin analizar los mensajes de excepción.
Antipatrón: define una excepción personalizada que solo existe para generarse una vez y nunca detectarse. Eso es simplemente "aumentar ValueError ("...")". Las excepciones personalizadas ganan peso al ser captadas.
Tres antipatrones que ocultan errores
Antipatrón 1: desnudo excepto
El except simple detecta señales que deberían salir del programa (Ctrl-C, sys.exit, MemoryError). Nunca escribas esto. Si realmente desea detectar todas las excepciones no fatales, utilice excepto excepción:, que TODAVÍA detecta demasiadas, pero al menos respeta Ctrl-C.
Antipatrón 2: silenciar sin iniciar sesión
Cada excepción detectada debe manejarse (con un respaldo específico) o registrarse. pass en una excepción es un error en cámara lenta: el código parece funcionar mientras descarta datos silenciosamente.
Antipatrón 3: excepto excepción: alrededor de todo
Problema: si stripe.charge tuvo éxito pero send_receipt falló, se le cobró al cliente Y usted se tragó el error. El "excepto" cubre cuatro modos de falla diferentes y no es posible distinguirlos.
Solución: reduzca el alcance de la prueba + bifurque el excepto por el límite del módulo.
Cada intento cubre UNA operación. Cada uno, excepto, sabe qué hacer con ESTE fallo específico. Eso es manejo de errores a nivel de producción.
Un buen manejo de errores es más diseño que sintaxis. probar/excepto/si no/finalmente te da las herramientas; la disciplina es elegir el tipo correcto excepto, el alcance de prueba más limitado posible y nunca silenciar los errores que no comprende.
Siguiente paso: la pista de Fundamentos tiene 10 lecciones sobre manejo de excepciones, excepciones personalizadas y la declaración with, con Python real ejecutándose en su navegador.