例外処理の実践ルール【catchとログの判断基準】

はじめに

例外処理でありがちな問題は次の3つです。

• 深い層で広く catch して、null や false を返して原因を消す
• 各層で同じ例外を重複ログして、ログがノイズだらけになる
• 最後の未処理例外ハンドラに回復を期待しすぎる

1. まず結論

• 深い層（helper等）では広くcatchしない
• catchするのは「失敗をどう扱うか判断できる境界」
• ログは1つの失敗に1回の主ログが基本
• 一番深い層の役割は後始末と例外の翻訳。再スローするなら主ログは出さない
• 画面操作、HTTPリクエスト、ジョブ1件などの「処理境界」が主ログの適地
• 想定内の失敗は結果化（例外として投げ続けない）

2. catch・ログ・エラーハンドリングは別物

3. 呼び出し階層ごとの役割

4. 各層の具体的な役割

4.1 深い層（helper/utility）

• やってよいこと: finally でのリソース解放、局所ロールバック、例外メッセージへの最小限の文脈追加
• やってはいけないこと: catch(Exception) して null/false/空配列を返す、ここでログを出す、UIを表示する

4.2 外部I/O境界（Repository/Gateway）

• HttpRequestException や IOException などの具体例外を受ける
• 「支払いサービス接続失敗」「CSV形式不正」などの意味のある例外に翻訳して再スロー
• retryするならここで（ただし冪等性がある場合のみ）
• 再スローするなら主ログは出さない

4.3 UseCase/Application Service

• 想定内の失敗（validation、NotFound、業務ルール違反）を結果型や失敗DTOにする
• 上位に「ユースケースとしての意味」までを決めて返す
• この層でUI表示やHTTP応答本文までは組み立てない

4.4 境界（UI/Controller/Job）

• 想定外例外をまとめて受ける
• requestId、userId、orderId付きで主ログを1回出す
• エラーダイアログ、HTTP 500、ジョブ失敗などへ変換

4.5 未処理例外ハンドラ

• 最終ログ、flush、dump収集、終了コード設定
• 回復を期待しない。ここまで来た時点で設計漏れ
• WPFの DispatcherUnhandledException などは、Handled = true で続行できるが、安全とは限らない

5. 失敗の種類を分ける

6. ログの鉄則

1. 1つの失敗に主ログ（Error/Critical）は1回
2. 下位層は翻訳と文脈追加のみ。主ログを出さない
3. 上位境界が文脈付きで主ログ
4. 飲み込む層だけが記録責任を持つ
5. 想定内の失敗は毎回Errorにしない
6. OperationCanceledException は障害ログと分ける（Debug/Informationで十分）

よくある重複ログのパターン

RepositoryがError → Serviceが同じ例外をError → ControllerがまたError → 未処理ハンドラでCritical

→ 同じスタックトレースが4本並ぶ。欲しいのは1本の主ログと最小限の補助ログです。

7. C#での注意点

// スタックトレースを壊さず再スロー
throw;  // OK

throw ex;  // NG: スタックトレースがリセットされる

8. まとめ

• 深い層は翻訳とcleanup。広くcatchしない
• 境界は判断と主ログ。責任を持てる場所で受ける
• ログは1回、文脈は必要なだけ
• 例外は境界で受け、回復できる場所だけで処理する

迷ったらこの順で考える:

1. この場所で本当に判断できるか
2. ここで失敗単位が分かるか
3. ここで状態を戻せるか
4. ここでログすると重複しないか
5. ここは回復地点か、最後の記録地点か