Revision de Manejo de Errores

El Problema

El manejo de errores es la dimension mas descuidada de la calidad del codigo. Los desarrolladores envuelven todo en try/catch y loguean a consola — tragandose silenciosamente fallos que deberian crashear ruidosamente. Las peticiones de red asumen exito. Los envios de formulario no muestran nada cuando la API retorna 500. El resultado: los usuarios ven pantallas en blanco, los datos se corrompen silenciosamente, y el debugging se convierte en arqueologia forense.

El Prompt

Revisa el manejo de errores en el siguiente codigo. Actua como un ingeniero de confiabilidad evaluando el comportamiento del sistema cuando las cosas salen mal.

LENGUAJE/FRAMEWORK: [ej. TypeScript/React, Python/FastAPI, Go]
CONTEXTO: [ej. procesamiento de pagos, registro de usuarios, carga de archivos]

CODIGO:
[pegar codigo aqui]

Evalua estas dimensiones de manejo de errores:

1. **Calidad del Catch**
   - Los catch son demasiado amplios (capturando Error en vez de tipos especificos)?
   - Los catch tragan errores silenciosamente (catch vacio, solo console.log)?
   - Los errores se re-lanzan cuando deberian burbujear?
   - El error original se preserva en excepciones envueltas (cause chaining)?

2. **Comunicacion al Usuario**
   - El usuario ve un mensaje util cuando algo falla?
   - Los estados de error estan disenados o la UI simplemente queda en blanco?
   - Los errores transitorios (red, timeout) se distinguen de los permanentes?
   - Hay mecanismo de reintento para fallos recuperables?

3. **Proteccion de Limites**
   - Las respuestas API se validan antes de usar?
   - Las operaciones de BD tienen rollback de transaccion en fallo?
   - Las llamadas a servicios externos tienen timeouts configurados?

4. **Propagacion de Errores**
   - La estrategia de propagacion es consistente (throw vs Result vs callback)?
   - El llamador puede distinguir entre tipos de error para decidir estrategia?
   - Los errores async se manejan (unhandled promise rejections)?

5. **Observabilidad**
   - Los errores se loguean con suficiente contexto (user ID, request ID)?
   - Las tasas de error se monitorean (no solo se loguean)?

Para cada problema, proporciona:
- **Ubicacion**: Archivo y linea
- **Modo de Fallo**: Que pasa en produccion
- **Severidad**: Fallo-silencioso / Mala-UX / Riesgo-datos / Crash
- **Fix**: Codigo de manejo de errores mejorado

Ejemplo de Salida

## Revision de Manejo de Errores: 5 problemas encontrados

### Fallo Silencioso: Error de BD Tragado
Ubicacion: src/services/user.ts:34
Codigo:
  try { await db.insert(user); }
  catch (e) { console.log('insert fallo'); }
Modo de Fallo: El usuario ve mensaje de exito pero los datos nunca se guardaron.
Fix:
  try { await db.insert(user); }
  catch (error) {
    logger.error('Insert de usuario fallo', { userId: user.id, error });
    throw new DatabaseError('No se pudo crear el usuario', { cause: error });
  }

Cuando Usar

Ejecutar en codigo que maneja entrada de usuario, peticiones de red, operaciones de BD o procesamiento de pagos. Esencial antes de deployments a produccion y despues de cualquier incidente donde “el error fue capturado pero nadie lo noto” fue la causa raiz.

Tips Pro

• Probar el camino infeliz — despues de la revision, pedir “Genera casos de prueba que ejerciten cada ruta de error.”
• Pedir taxonomia de errores — “Categoriza todos los posibles errores en recuperables (retry), corregibles por el usuario (errores de formulario), y fatales (pagina de error).”
• Verificar error boundaries — en apps React, preguntar “Donde deberian colocarse Error Boundaries para prevenir que toda la app crashee?”