Manejo de errores
Define los fallos, sus propietarios y qué permanece seguro después de un fallo. Esto es una guía, no una lista de verificación.
Fallos tipificados y estructurados
Los fallos esperados necesitan tipos declarados, discriminantes estables y detalles relevantes para el manejo. Reutiliza las convenciones de error del proyecto, preserva las causas y separa la identidad de la máquina del texto de visualización. Nunca dirijas el manejo analizando mensajes. Los defectos inesperados, como una verificación de exhaustividad fallida, pueden permanecer como errores simples; la contención nunca debe convertirlos en éxito.
Capturar, recuperar o detener
Para cada fallo, define los propietarios del manejo y reporte, la contención y las garantías en la documentación de la API propietaria: qué invariantes permanecen válidas, si los efectos están ausentes, son parciales, confirmados o desconocidos, y quién es responsable de la limpieza. El trabajo en segundo plano mantiene estas obligaciones.
La captura limita la propagación de excepciones, no las mutaciones. Solo el propietario del estado afectado puede establecer una continuación segura. De lo contrario, detén el trabajo dependiente, descarta el estado o las instancias inválidas, o escala. El registro por sí solo no es recuperación. Los reintentos requieren repetición segura, cancelación y un propietario explícito; las operaciones finitas necesitan presupuestos, mientras que la supervisión continua necesita propiedad del ciclo de vida y degradación observable.
Reportes localizados, accionables y visibles
Cada reporte final necesita un resumen legible, la operación afectada y una acción segura a seguir. Localiza a través del mecanismo de configuración regional de la aplicación receptora donde exista; otros diagnósticos usan su idioma de salida existente. Mantén los detalles internos sensibles fuera del texto visible para el usuario.
El estado no confiable o los resultados desconocidos deben ser visibles a través de la interfaz de usuario o registros accesibles habilitados por defecto: reporta el impacto, la incertidumbre, lo que hizo el sistema y el siguiente paso seguro. El estado inválido persistente necesita visibilidad persistente. Nunca afirmes éxito, reversión o reintento seguro sin las garantías que los respaldan. Los fallos de reporte necesitan una alternativa independiente.
Verifica el estado resultante y el resultado visible, no solo que se haya capturado una excepción.
Fundamentos
Meyer, Object-Oriented Software Construction (1997): contratos e invariantes. Sutter, Exceptional C++ (1999): garantías de seguridad ante excepciones. Armstrong, Making reliable distributed systems in the presence of software errors (2003): aislamiento y supervisión.