Fehlerbehandlung
Definieren Sie Fehler, deren Eigentümer und was nach einem Fehler sicher bleibt. Dies ist eine Leitlinie, keine Checkliste.
Typisierte, strukturierte Fehler
Erwartete Fehler benötigen deklarierte Typen, stabile Diskriminanten und handlungsrelevante Details. Verwenden Sie die Fehlerkonventionen des Projekts wieder, bewahren Sie Ursachen und trennen Sie die maschinelle Identität vom Anzeigetext. Leiten Sie die Behandlung niemals durch das Parsen von Nachrichten. Unerwartete Defekte, wie etwa das Scheitern einer Vollständigkeitsprüfung, können einfache Fehler bleiben; Eindämmung darf sie niemals in Erfolge verwandeln.
Abfangen, Wiederherstellen oder Stoppen
Definieren Sie für jeden Fehler die Eigentümer der Behandlung und Berichterstattung, die Eindämmung und die Garantien in der Dokumentation der besitzenden API: welche Invarianten gültig bleiben, ob Effekte abwesend, teilweise, festgeschrieben oder unbekannt sind und wer für die Bereinigung verantwortlich ist. Hintergrundarbeit behält diese Verpflichtungen.
Das Abfangen begrenzt die Ausbreitung von Ausnahmen, nicht von Mutationen. Nur der Eigentümer des betroffenen Zustands kann eine sichere Fortsetzung herstellen. Andernfalls stoppen Sie abhängige Arbeiten, verwerfen Sie ungültige Zustände oder Instanzen oder eskalieren Sie. Alleiniges Protokollieren ist keine Wiederherstellung. Wiederholungen erfordern sichere Wiederholbarkeit, Abbrechbarkeit und einen expliziten Eigentümer; endliche Vorgänge benötigen Budgets, während kontinuierliche Überwachung Lebenszyklus-Eigentümerschaft und beobachtbare Verschlechterung benötigt.
Lokalisierte, umsetzbare, sichtbare Berichte
Jeder endgültige Bericht benötigt eine lesbare Zusammenfassung, die betroffene Operation und eine sichere nächste Aktion. Lokalisieren Sie über den Lokalisierungsmechanismus der empfangenden Anwendung, falls vorhanden; andere Diagnosen verwenden ihre vorhandene Ausgabesprache. Halten Sie vertrauliche interne Details aus benutzersichtbaren Texten heraus.
Nicht vertrauenswürdige Zustände oder unbekannte Ergebnisse müssen über die Benutzeroberfläche oder standardmäßig aktivierte, zugängliche Protokolle sichtbar sein: Melden Sie die Auswirkung, die Unsicherheit, was das System getan hat und den sicheren nächsten Schritt. Dauerhaft ungültiger Zustand benötigt dauerhafte Sichtbarkeit. Beanspruchen Sie niemals Erfolg, Rollback oder sichere Wiederholung ohne die dahinterstehenden Garantien. Fehler bei der Meldung benötigen einen unabhängigen Fallback.
Überprüfen Sie den resultierenden Zustand und das sichtbare Ergebnis, nicht nur, ob eine Ausnahme abgefangen wurde.
Grundlagen
Meyer, Object-Oriented Software Construction (1997): Verträge und Invarianten. Sutter, Exceptional C++ (1999): Ausnahmesicherheitsgarantien. Armstrong, Making reliable distributed systems in the presence of software errors (2003): Isolation und Überwachung.