Gestion des erreurs
Définissez les échecs, leurs responsables, et ce qui reste sûr après un échec. Ceci est un guide, pas une liste de contrôle.
Échecs typés et structurés
Les échecs attendus nécessitent des types déclarés, des discriminants stables et des détails pertinents pour leur traitement. Réutilisez les conventions d'erreur du projet, préservez les causes et séparez l'identité machine du texte affiché. Ne dirigez jamais le traitement en analysant les messages. Les défauts inattendus, comme un échec de vérification d'exhaustivité, peuvent rester des erreurs simples ; la confinement ne doit jamais les transformer en succès.
Capturer, récupérer ou arrêter
Pour chaque échec, définissez les responsables de la gestion et du rapport, le confinement et les garanties dans la documentation de l'API propriétaire : quels invariants restent valides, si les effets sont absents, partiels, validés ou inconnus, et qui est responsable du nettoyage. Les tâches en arrière-plan conservent ces obligations.
La capture limite la propagation des exceptions, pas les mutations. Seul le propriétaire de l'état affecté peut établir une continuation sûre. Sinon, arrêtez le travail dépendant, écartez l'état ou les instances invalides, ou escaladez. La journalisation seule n'est pas une récupération. Les tentatives nécessitent une répétition sûre, une annulation et un propriétaire explicite ; les opérations finies ont besoin de budgets, tandis que la supervision continue nécessite une propriété de cycle de vie et une dégradation observable.
Rapports localisés, exploitables et visibles
Chaque rapport final a besoin d'un résumé lisible, de l'opération affectée et d'une action suivante sûre. Localisez via le mécanisme de locale de l'application réceptrice lorsqu'il existe ; les autres diagnostics utilisent leur langue de sortie existante. Gardez les détails internes sensibles hors du texte destiné à l'utilisateur.
L'état non fiable ou les résultats inconnus doivent être visibles via l'interface utilisateur ou des logs accessibles et activés par défaut : rapportez l'impact, l'incertitude, ce que le système a fait et l'étape suivante sûre. Un état invalide persistant nécessite une visibilité persistante. Ne revendiquez jamais un succès, une restauration ou une tentative sécurisée sans les garanties qui les soutiennent. Les échecs de rapport nécessitent une solution de repli indépendante.
Vérifiez l'état résultant et le résultat visible, pas seulement qu'une exception a été capturée.
Fondements
Meyer, Object-Oriented Software Construction (1997) : contrats et invariants. Sutter, Exceptional C++ (1999) : garanties de sécurité des exceptions. Armstrong, Making reliable distributed systems in the presence of software errors (2003) : isolation et supervision.