Python Try Except para Scrapers Web Confiables 2026
Python try except es la diferencia entre un scraper que se detiene después de una mala solicitud y un crawler que sigue funcionando a través de fallos de red. En el scraping en producción, los errores son normales. Un servidor puede agotarse, un proxy puede fallar, una página puede devolver un 403, o un selector puede romperse después de un cambio en el diseño. Esta guía explica try, except, else, y finally a través de la lente de crawlers de alta disponibilidad. Está escrita para desarrolladores de Python que ya envían solicitudes HTTP y ahora necesitan un manejo de fallos más seguro. Aprenderás cómo capturar excepciones específicas, reintentar con retroceso, rotar proxies, liberar recursos y usar Nstdata como parte de un flujo de trabajo de proxy estable.
Principales Conclusiones
Usa python try except para manejar fallos esperados del crawler sin ocultar errores.
Captura excepciones específicas como Timeout, ProxyError, y HTTPError.
Usa else para analizar solo después de una solicitud exitosa.
Usa finally para limpieza, cierre de sesión y métricas.
Combina la lógica de reintento con la rotación de proxies cuando los fallos de red se repiten.
Excepciones Comunes en Web Scraping
Los scrapers fallan en patrones, por lo que el manejo de excepciones debe coincidir con esos patrones. Trata los errores de red, errores de proxy, errores de estado HTTP y errores de análisis como eventos diferentes.
La documentación oficial de requests enumera excepciones como Timeout, TooManyRedirects, y HTTPError en su guía de errores y excepciones. Python también documenta el manejo de excepciones en Errores y Excepciones.
La regla clave es simple. Captura lo que puedes recuperar. Deja que los errores desconocidos aparezcan durante el desarrollo.
Fundamentos de Python Try Except para Crawlers
Python try except debe proteger solo la operación arriesgada. En un crawler, eso generalmente significa la solicitud, la verificación de estado, el paso del analizador o el paso de almacenamiento. Mantén cada bloque lo suficientemente pequeño como para explicarlo.
import requests
url ="https://example.com/products"try: response = requests.get(url, timeout=10) response.raise_for_status()except requests.exceptions.Timeout:print("La solicitud ha superado el tiempo de espera; programa un reintento.")except requests.exceptions.HTTPError as exc:print(f"Error HTTP: {exc.response.status_code}")except requests.exceptions.RequestException as exc:print(f"Error de red: {exc}")else: html = response.text
print("Es seguro analizar la página ahora.")
Este patrón es mejor que un except: amplio. Separa los tiempos de espera, los errores HTTP y los fallos generales de solicitud. También mantiene el análisis en el bloque else, que se ejecuta solo después de que la solicitud tiene éxito.
Evita este patrón en producción:
try: response = requests.get(url)except:pass
Oculta errores reales. También crea brechas de datos silenciosas, que son más difíciles de arreglar que los errores visibles.
Captura de Errores de Proxy y Rotación de IPs
Los errores de proxy necesitan su propia rama porque la solución es diferente de un reintento normal. Si un endpoint de proxy falla, repetir la misma solicitud a través del mismo proxy puede desperdiciar tiempo. El scraper debe marcar el proxy como no saludable e intentar con otro.
import requests
deffetch_with_proxy(url, proxy): proxies ={"http": proxy,"https": proxy,}try: response = requests.get(url, proxies=proxies, timeout=12) response.raise_for_status()except requests.exceptions.ProxyError:return{"ok":False,"reason":"error_proxy","retry":True}except requests.exceptions.Timeout:return{"ok":False,"reason":"tiempo_de_espera","retry":True}except requests.exceptions.HTTPError as exc: status = exc.response.status_code
return{"ok":False,"reason":f"http_{status}","retry": status in(403,407,429)}except requests.exceptions.RequestException as exc:return{"ok":False,"reason":str(exc),"retry":True}else:return{"ok":True,"html": response.text}
Esta estructura hace que las decisiones de reintento sean explícitas. Un ProxyError puede desencadenar un reemplazo de proxy. Un 429 puede desencadenar una desaceleración. Un 403 puede desencadenar la revisión de encabezados, comportamiento de sesión o calidad de proxy.
Nstdata se adapta naturalmente aquí. Si tu raspador utiliza una piscina de proxies rotativos, Nstdata puede proporcionar fuentes de proxy más limpias para flujos de reintento. Su rotación inteligente de IP y cobertura global reducen la probabilidad de bloqueos, CAPTCHAs y límites de velocidad, lo que permite a los raspadores acceder a información pública a gran escala.
El bloque else es mejor para trabajos que deberían ejecutarse solo después de que no ocurra ninguna excepción. En raspado, coloca el análisis o la extracción allí. Esto evita que tu analizador se ejecute en una respuesta perdida o fallida.
El bloque finally es mejor para la limpieza. Úsalo para cerrar sesiones, liberar páginas del navegador, actualizar métricas o devolver un token de proxy a una piscina. Evita la lógica empresarial compleja en finally.
session = requests.Session()try: response = session.get(url, timeout=10) response.raise_for_status()except requests.exceptions.RequestException as exc: logger.warning("fetch_failed", extra={"url": url,"error":str(exc)})else: title = parse_title(response.text) save_record(url, title)finally: session.close()
Esto se lee como un ciclo de vida de un rastreador. Intenta la solicitud. Maneja fallos conocidos. Analiza solo en caso de éxito. Limpia cada vez.
La documentación de Python también admite volver a lanzar excepciones cuando el llamador debe decidir qué sucede a continuación. Eso es útil cuando una función de recuperación de bajo nivel no debería ocultar un fallo del programador de trabajos.
Estrategia de Reintento en Producción
La lógica de reintento en producción debe ser limitada, observable y educada. Reintentos infinitos pueden sobrecargar un sitio objetivo y desperdiciar ancho de banda de proxy. Un patrón más seguro es el retroceso exponencial con jitter, límites de reintento y decisiones informadas sobre el estado.
El proyecto urllib3 documenta una utilidad de Retry para manejar el comportamiento de reintento en clientes HTTP. Consulta urllib3 Retry para los conceptos subyacentes.
Disparador de Reintento
¿Reintentar?
Acción Extra
Tiempo de espera
Sí
Aumentar el retroceso
Error de Proxy
Sí
Reemplazar proxy
403
A veces
Revisar encabezados y reputación del proxy
407
Sí
Verificar autenticación del proxy
429
Sí
Reducir la velocidad y rotar IP
404
No
Registrar página faltante
Error de analizador
No reintentar inmediatamente
Registrar HTML de ejemplo
El código de producción debe registrar cada intento. Incluye URL, código de estado, tipo de excepción, ID de proxy, conteo de reintentos y resultado final. Estos campos te ayudan a separar proxies malos de analizadores malos.
Nstdata puede reducir el ruido a nivel de red al dar a los rastreadores una fuente de proxy gestionada en lugar de proxies gratuitos aleatorios. Los equipos también pueden utilizar el verificador de proxies gratis durante diagnósticos y proxies residenciales para flujos de trabajo que necesitan perfiles de red realistas.
Resumen de Comparación: Simple Try Except vs Manejo en Producción
Ejemplos simples de python try except son buenos para aprender. Los raspadores de producción necesitan más estructura porque la misma excepción puede significar diferentes acciones.
Área
Patrón para Principiantes
Patrón para Raspadores en Producción
Tipo de excepción
Capturar todos los errores
Capturar excepciones específicas
Manejo de Proxy
Reintentar la misma solicitud
Reemplazar el proxy ante fallos del proxy
Estado HTTP
Ignorar o imprimir
Enrutar por 403, 407, 429, 5xx
Registro
Salida de consola
Registros estructurados con ID de proxy
Reintento
Bucle manual
Retroceso, jitter, intentos máximos
Análisis
Analizar dentro de try
Analizar en else después del éxito
Limpieza
A menudo omitido
finally cierra sesiones
Flujo de Trabajo Práctico para un Raspador de Alta Disponibilidad
Un rastreador estable debería tratar los fallos como datos. Cada solicitud fallida debería actualizar la siguiente decisión.
Usa este flujo de trabajo:
Elige una URL y un proxy.
Envía la solicitud con un tiempo de espera.
Captura excepciones específicas de red y proxy.
Reintenta con retroceso cuando el error sea recuperable.
Rota el proxy ante ProxyError, 407, 403 repetidos o 429 repetidos.
Analiza solo después de una respuesta limpia.
Registra el resultado final.
Almacena URLs fallidas para revisión posterior.
Este flujo de trabajo mejora la tasa de supervivencia sin ocultar defectos reales. También ayuda a los equipos a decidir cuándo el problema es la página objetivo, el analizador, el patrón de solicitud o la piscina de proxies.
Permite que Python ejecute código arriesgado en un bloque try y maneje fallos esperados en uno o más bloques except. En raspadores, previene que una solicitud fallida detenga todo el trabajo.
¿Debería capturar Exception en un raspador?
Captura primero excepciones específicas. Usa Exception solo en un límite donde registras el error y mantienes vivo el trabajo. Evita except: sin parámetros porque puede ocultar errores.
¿Cómo manejo errores de proxy en solicitudes de Python?
Captura requests.exceptions.ProxyError, marca el proxy como no saludable, y luego intenta de nuevo con un proxy diferente. También registra el ID del proxy, la URL y el conteo de reintentos.
¿Debería el código de análisis ir dentro de try o else?
Coloca el análisis en else cuando dependa de una solicitud exitosa. Esto evita que las respuestas fallidas lleguen a tu analizador.
¿Cómo ayuda Nstdata a la fiabilidad del raspador?
Nstdata proporciona una infraestructura de proxy que puede soportar reintentos y flujos de trabajo de rotación de IP. Ayuda a reducir fallos causados por fuentes de proxy de baja calidad o inestables.
Conclusión
try except en Python es más que una sintaxis para principiantes cuando construyes raspadores web. Es la capa de control que mantiene vivos los trabajos a través de tiempos de espera, fallos de proxy, bloqueos HTTP y cambios en el analizador.
Comienza pequeño. Captura excepciones específicas. Usa else para el análisis y finally para la limpieza. Agrega reintentos limitados con retroceso. Rote proxies cuando el fallo esté relacionado con la red. Para equipos que necesitan una infraestructura de proxy más estable, Nstdata es una opción práctica para flujos de trabajo de raspado en Python.
Los motores de búsqueda son construidos por rastreadores, mientras que sus páginas de resultados son servicios separados. Este artículo explica las medidas y los límites de acceso que siguen.
Kai Watanabe
Oct. 23rd 2026
110M+ IP reales con 99.9% de acceso exitoso
Respuesta media ultrarrapida ~0.5s para tareas de alta concurrencia
Desde solo $0.1/GB
Acceso inmediato a pools premium de proxies residenciales, datacenter, IPv6 e ISP.
