エラー処理
障害、その所有者、および障害後も安全な状態を定義します。これはチェックリストではなくガイダンスです。
型付きの構造化された障害
予期される障害には、宣言された型、安定した判別子、および処理に関連する詳細が必要です。プロジェクトのエラー規則を再利用し、原因を保持し、機械的な識別子と表示テキストを分離します。メッセージを解析してルーティングしてはいけません。網羅性チェックの失敗など、予期しない欠陥は単純なエラーのままでも構いませんが、封じ込めによって決して成功に変えてはいけません。
キャッチ、リカバリ、または停止
各障害について、処理と報告の所有者、封じ込め、および保証を所有APIドキュメントに定義します：どの不変条件が有効か、副作用がないか、部分的か、コミット済みか、不明か、およびクリーンアップの責任者は誰か。バックグラウンド処理もこれらの義務を負います。
キャッチは例外の伝播を制限するものであり、変更を制限するものではありません。影響を受けた状態の所有者だけが安全な継続を確立できます。それ以外の場合は、依存する作業を停止し、無効な状態やインスタンスを破棄するか、エスカレーションします。ログ記録だけではリカバリにはなりません。リトライには、安全な繰り返し、キャンセル、および明示的な所有者が必要です。有限な操作には予算が必要であり、継続的な監督にはライフサイクルの所有権と観測可能な劣化が必要です。
ローカライズされ、実用的で、可視化されたレポート
すべての最終レポートには、読みやすい要約、影響を受けた操作、および安全な次のアクションが必要です。受信アプリケーションのロケールメカニズムが存在する場合はそれを通じてローカライズします。その他の診断は既存の出力言語を使用します。機密内部詳細はユーザー向けテキストに含めないでください。
信頼できない状態や未知の結果は、UIまたはデフォルトで有効なログを通じて可視化する必要があります：影響、不確実性、システムの対応、および安全な次のステップを報告します。持続的に無効な状態には持続的な可視性が必要です。裏付けとなる保証なしに、成功、ロールバック、または安全なリトライを決して主張してはいけません。障害報告には独立したフォールバックが必要です。
結果の状態と可視化された結果を検証し、例外がキャッチされたことだけを確認しないでください。
基礎
Meyer, Object-Oriented Software Construction (1997): 契約と不変条件。Sutter, Exceptional C++ (1999): 例外安全性保証。Armstrong, Making reliable distributed systems in the presence of software errors (2003): 隔離と監督。