【2026年最新】例外処理をどこに書くか｜判断基準7つと握りつぶさない設計

失敗する可能性のある処理には、例外への対応が必要です。ただしすべての箇所で捕まえると、コードが読みにくくなり、かえって原因が追えなくなります。この記事では、どこで捕まえ、どこで捕まえないかの判断基準を整理します。

判断基準7つ

【結論】そこで何ができるかで決めます。

1. 対処できるか

代替の値を使う、再試行する、利用者に伝えるといった行動が取れるなら、その場で捕まえます。何もできないなら、呼び出し元へ流してください。

2. 想定内か想定外か

入力が正しくないといった想定内の失敗は、その場で処理します。想定外の状態は、上位でまとめて扱うほうが整理できます。

3. 情報を追加できるか

「どのファイルを開こうとして失敗したか」といった文脈を足せるなら、捕まえて情報を付けてから流す価値があります。

4. 利用者に見せる必要があるか

画面に表示する必要があるなら、表示を担当する層で捕まえます。内部の処理で捕まえると、伝える手段がありません。

5. 記録が必要か

記録を残すのは、原則として1か所にしてください。各層で記録すると、同じ失敗が何度も出力されます。

6. 処理を続けられるか

一部が失敗しても全体を続けるべき場面があります。複数の対象を順に処理する場合、1件の失敗で全体を止めるかどうかは設計の判断です。

7. 資源を解放する必要があるか

ファイルや接続を開いている場合、失敗しても確実に閉じる必要があります。これは捕まえるかどうかとは別に、必ず行う処理です。

状況	捕まえる	理由
代替値で継続できる	する	その場で対処可能
再試行で解決しうる	する	その場で対処可能
利用者へ表示する	表示層でする	伝える手段がある
何もできない	しない	上位へ流す
記録だけしたい	1か所でする	重複を避ける

握りつぶしの害

【結論】原因を消し去ります。

何が起きるか

捕まえたのに何も記録せず、何も対処しない書き方をすると、失敗がなかったことになります。処理は続きますが、結果は不正確です。

調査ができない

後から不具合が報告されても、記録に何も残っていません。どこで何が起きたか追えず、再現も困難になります。

より悪い状態

失敗を無視して処理が進むと、不正な値のまま次の処理に渡ります。本来止まるべき場所で止まらず、別の場所で分かりにくい形で表面化します。

やむを得ない場合

意図的に無視する場面もあります。その場合、無視してよい理由をコメントに残してください。将来の読み手が判断できます。

捕まえる範囲

【結論】広く捕まえないでください。

すべての例外を捕まえる

あらゆる例外を1つの処理で受けると、想定していなかった不具合まで隠れます。プログラムの誤りによる例外も同じ扱いになります。

種類を絞る

ファイルが見つからない、接続に失敗した、といった具体的な種類を指定して捕まえてください。想定していない例外は上へ流れます。

範囲を狭くする

失敗する可能性のある1行だけを囲むのが理想です。広く囲むと、どの処理で失敗したか分からなくなります。

複数の種類がある場合

種類ごとに分けて記述すれば、それぞれに適した対処ができます。まとめて扱うと、対処も画一的になります。

情報を足して流す

【結論】元の情報を失わないでください。

文脈を付ける

「設定の読み込みに失敗した」という情報を足して、元の例外とともに流します。どの段階で起きたかが分かります。

元の例外を保持する

新しい例外を作って流す場合、元の例外を原因として含めてください。これを省くと、根本の原因が消えます。

種類を変える

内部の詳細をそのまま外へ出さず、その層に適した種類へ変換する方法があります。外部の実装に依存しない設計になります。

やりすぎない

層ごとに変換を重ねると、追うのが煩雑になります。必要な境界だけで行ってください。

再試行の設計

【結論】何でも再試行してよいわけではありません。

再試行してよい失敗

一時的な通信の失敗、混雑による拒否など、時間を置けば成功する可能性があるものです。

再試行してはいけない失敗

認証の失敗、入力の誤り、権限の不足など、何度試しても結果が変わらないものです。無駄な負荷をかけるだけになります。

間隔をあける

即座に繰り返すと相手に負荷をかけます。間隔を徐々に広げる方式が一般的です。

回数の上限

無限に繰り返さないよう、上限を決めてください。上限に達したら失敗として扱います。

資源の解放

【結論】言語の仕組みを使ってください。

確実に閉じる

ファイルや接続は、成功しても失敗しても閉じる必要があります。多くの言語に、この用途の構文が用意されています。

手動で書く危険

例外が起きたときの経路を自分で書くと、漏れが生じます。専用の構文を使えば、どの経路でも実行されます。

複数の資源

複数を同時に扱う場合、開いた順と逆に閉じるのが原則です。構文を使えば自動的にそうなります。

解放時の失敗

閉じる処理自体が失敗することもあります。この場合、元の例外を隠さないよう注意が必要です。

よくある質問（FAQ）

Q1. とりあえず捕まえておくのは駄目ですか

対処も記録もしないなら害になります。捕まえない選択のほうが安全です。

Q2. どこで記録すべきですか

原則として1か所です。各層で記録すると、同じ失敗が何度も出力されます。

Q3. すべての例外を捕まえてはいけませんか

最上位で最後の受け皿として置く場合はあります。それ以外の場所では、種類を絞ってください。

Q4. 独自の例外を作るべきですか

その層の意味を表現できるなら有効です。ただし数が増えすぎると管理が煩雑になります。

Q5. 再試行は何回が適切ですか

3回程度が一般的です。相手の状況と、待てる時間で決めてください。

Q6. 意図的に無視したい場合は

理由をコメントに残してください。何も書かないと、書き忘れと区別がつきません。

まとめ

例外を捕まえるかどうかは、その場で何ができるかで決まります。代替の値を使う、再試行する、利用者に伝えるといった行動が取れないなら、捕まえずに上へ流してください。

最も避けるべきは、捕まえたのに何もしない書き方です。失敗がなかったことになり、記録にも残らず、不正な値のまま処理が続きます。

捕まえる範囲は狭くしてください。あらゆる例外を1つの処理で受けると、想定していなかった不具合まで隠れます。種類を指定し、失敗しうる行だけを囲むのが理想です。

再試行は、時間を置けば成功しうる失敗にのみ有効です。認証の失敗や入力の誤りは何度試しても変わらないため、無駄な負荷をかけるだけになります。

📱 運営の裏側・最新情報はXで発信中 → @ore_chusotsu