1 例外処理の概要
例外処理とは、プログラムの実行中に発生する「通常の手順では扱えない事象（例外）」を検知し、あらかじめ定めた手続きによって安全に回復・中断・代替処理を行う仕組みである。単にエラーを止めるのではなく、状況に応じて適切な判断へ導くことで、システムの信頼性と保守性を高める。
例外処理は、言語ごとの構文（例外の送出・捕捉・後処理の記述など）と、設計上の方針（どこで例外を使うか、ログや通知をどう残すか、整合性をどう守るか、境界で責務をどう分けるか）で成り立つ。本項目では、概念から実装、運用・テストへと一連の考え方を体系化する。
1.1 例外とは何か
例外は、プログラムの通常の前提が崩れたときに発生する「制御の特別な転換」である。処理系は通常フローから逸脱し、例外捕捉側へと制御が移る。ここで重要なのは、例外が「異常を示す情報」であり、同時に「どのように扱うべきか」という意思決定の入力にもなる点である。
1.1.1 例外とエラーの違い
エラーは広義に、計算や入出力などの結果が期待と不一致である状態を指すことが多い。一方、例外は多くの言語で、エラー状態を表すための特別な伝達機構として定義される。結果として、エラーの表現方法は複数あり得るが、例外はそのうちの「制御フローを転換する」方式として位置づけられる。
1.1.2 通常フローとの関係
通常フローは、想定された条件が満たされる限り一本道に進む。例外は、その前提が破れた場合にのみ起動されるため、設計では「例外は例外的に起こる」ことを前提に扱うのが基本となる。頻発する事象を例外で制御し始めると、可読性や性能、予測可能性に影響が出やすい。
1.2 例外処理の目的
例外処理の中心的な狙いは、異常時でもシステムを破綻させず、適切な回復や停止、もしくは代替の道筋を確保することにある。これにより、単なるクラッシュ回避ではなく、健全な挙動の保証へ近づく。
1.2.1 安全性の確保
安全性とは、データ破損や資源リーク、整合性の喪失を防ぐことを含む。例外発生時に後処理や巻き戻し、あるいは整合性維持のための処置が実行されるよう設計することで、失敗しても被害が局所化され、回復可能性が高まる。
1.2.2 デバッグ容易性の向上
例外は「何が起きたか」を構造化して伝えるため、追跡や再現に役立つ。加えて、スタック情報や文脈（操作の種類、入力の性質、相関IDなど）を併せて扱うと、障害の原因究明が速くなる。握りつぶさない方針は、結果としてデバッグ負担を軽減する。
1.2.3 保守性と拡張性
例外の契約（どの失敗をどの例外型として表すか、捕捉側は何を期待するか）が明確になるほど、後から機能を追加しても影響範囲を推定しやすくなる。責務の境界が保たれると、変更時の混乱も減り、拡張がしやすくなる。
2 例外のライフサイクル
例外は、発生してから捕捉されるまでに複数の段階を経る。各段階における責務と設計の整合が取れているかが、最終的な品質を左右する。
2.1 例外の発生
例外が発生する局面は、「通常の前提が成立しない」瞬間である。ここでは、例外を起点に制御が切り替わるため、発生条件と表現の妥当性が特に重要になる。
2.1.1 送出（スロー）される条件
例外を送出する条件は、実装者が恣意的に決めるのではなく、契約の観点から整理されることが望ましい。事前条件の不成立、事後条件の不達成、不変条件の破壊などの区分を用いると、意味のある失敗として提示しやすくなる。
2.1.1.1 事前条件・事後条件・不変条件との整合
事前条件は処理に入る前に満たされるべき条件であり、ここが崩れるなら入力や状態の問題として扱える。事後条件は処理が終わった後に成立すべき性質であり、結果が期待を満たさない場合に対応が必要になる。不変条件は常に維持されるべきルールで、これが崩れるなら内部整合性の欠如として扱うのが一般的である。
2.2 伝播（プロパゲーション）
例外が捕捉されない場合、制御は呼び出し元へと戻り、適切な場所で扱われるまで伝播する。伝播の過程で、情報が失われないようにすることが求められる。
2.2.1 呼び出しスタックの探索
多くの実装では、例外送出後に捕捉可能なハンドラを呼び出しスタック上で探索する。この探索は「どの層で扱うか」を暗黙に決めてしまうため、捕捉範囲や例外型の階層設計に注意が必要となる。
2.2.2 境界での扱い方
層の境界（APIの入口、UIからサービスへの切替、データアクセスの切替など）では、例外をそのまま通すか、変換して渡すか、ログを残すかを意識する。目的は一貫性のある契約を保ちつつ、適切な観測点を確保することである。
2.3 捕捉と復旧
捕捉とは、例外に対して制御の行き先を定め、復旧の可能性を判断する行為である。捕捉しないことも選択肢であり、そのときは上位が適切な場所で判断できる状態を維持する必要がある。
2.3.1 捕捉すべき例外の選定
捕捉対象の選定は、回復可能性と責務の範囲で決める。特定の操作に固有の失敗は、その操作を理解している層が扱うべきである。一方、原因の解釈が難しい場合に広く捕捉すると、処理の意味が曖昧になり、後続の不具合を招く。
2.3.2 リカバリ戦略（再試行・代替・中断）
リカバリには複数の型がある。再試行は一時的な障害を想定し、間隔や上限を設けて破滅的な負荷を避ける。代替は別経路の処理へ切替え、ユーザー影響を軽減する。中断は安全な停止として機能し、整合性を壊さないために使われる。
2.4 後処理の実行
例外は制御を飛ばすため、通常の終了経路で行う処理（後処理や解放）が実行されないことがある。そこで、例外でも必ず実行される後処理を設計に組み込む。
2.4.1 finally相当の役割
多くの言語には、成功失敗を問わず必ず実行される節に相当する仕組みがある。これは、後続の状態を壊さないための最後の安全策として位置づけられる。例外が起きても処理の完了条件を満たすように記述することが基本となる。
2.4.2 リソース解放と整合性
後処理では、ファイルやネットワーク接続、ロック、メモリなどの資源を適切に解放する。また、トランザクションや整合性の確保に関しては、巻き戻しや無効化の実行タイミングが重要になる。安全側に倒すことが、結果的に全体の安定へ寄与する。
3 設計方針
設計方針は、例外を「いつ使い、どこで扱い、どの情報を残すか」を決める活動である。実装が整ったとしても、方針が曖昧だと運用で矛盾が噴き出す。
3.1 例外を使うべき場面
例外は万能ではない。戻り値や検証による制御と比較して、例外が適する条件を見極めることで、保守性が向上する。
3.1.1 異常系の分類（想定内・想定外）
想定内は、入力の妥当性が崩れ得るなど「起こりうるが正常ではない」状態である。想定外は、論理の矛盾や環境の重大な破綻のように、通常の業務継続を前提に扱いにくい状態に相当する。例外は特に想定外に対する伝達として有効であるが、想定内でも回復可能性があるなら使い方を設計する余地がある。
3.1.2 戻り値との使い分け
戻り値による失敗表現は、頻度が高い制御や、呼び出し側が毎回判断しやすい場合に適する。例外は、失敗が連鎖しやすい深い層へまで伝えたい場合、または失敗時の処理が非通常である場合に適しやすい。双方の境界をチームで定めると、散らばりを防げる。
3.2 例外の設計
例外型は「分類」と「説明」を同時に担う。設計の質は、ログの読みやすさや捕捉のしやすさに直結する。
3.2.1 例外型の命名と階層
命名は、意味が推測できる粒度を保つことが望ましい。階層は、共通の捕捉を行う場合に役立つ。基底型にまとめるべき性質と、固有の分岐が必要な性質を分けることで、捕捉側の意図が明確になる。
3.2.2 エラーメッセージと文脈情報
メッセージは、人が読んで状況を理解できるようにする。さらに、操作名、対象ID、入力の形式など、文脈を併せて提示すると、再現や調査に有利になる。単なる「失敗しました」ではなく、何がどうなったかを要約する。
3.2.3 例外に添える情報（原因・コード）
原因を示す情報や、分類用のコードを例外に含めると、機械的な集計やルーティングがしやすい。特に外部連携では、応答ステータスやエラーコードなど、調査に直結する値を整理して渡すと効果が高い。
3.3 責務分担とレイヤ構造
例外処理は、どの層がどこまで面倒を見るかという責務分担と対になっている。境界で責務が曖昧だと、二重捕捉や取りこぼしが起きやすくなる。
3.3.1 層ごとの例外ポリシー
例えばUI層はユーザー向けの通知や簡潔な表示を行い、サービス層は業務ルールに基づく復旧や変換を担い、データ層は永続化や外部依存の失敗を適切に分類する、といった役割分担が考えられる。ポリシーは文書化され、開発者の迷いを減らすべきである。
3.3.2 UI・サービス・データ層の整合
UI層が内部詳細をそのまま曝すと情報過多になり、逆にサービス層が握りつぶすと原因が消える。整合を取るには、例外の変換点と、どの層がログを残すか、どの層が表示文言を決めるかを揃える必要がある。
3.4 例外の伝達と変換
例外は伝播するだけでなく、文脈に応じて変換されることが多い。変換を適切に行うと、上位が判断しやすくなる。
3.4.1 ラップ（包む）と再送出
下位層の例外を上位へ渡す際に、上位の意味づけを保つためにラップして再送出する手法がある。これにより、原因は保持しつつ、上位の契約に沿った表現へ揃えられる。ラップ時に元の情報を失わない設計が重要になる。
3.4.2 型の変換ルール
変換ルールは「どの入力失敗がどの分類へ対応するか」「どの環境障害はどの上位型になるか」などを明確化する。ルールがない場合、似た状況で別の型が出続け、捕捉の網羅性が崩れていく。
4 実装のベストプラクティス
実装上の細部は、例外処理の効果を左右する。方針をコードへ落とし込む際の注意点として整理する。
4.1 捕捉の粒度
捕捉範囲の設計は、過剰な抑制と調査不能の双方を避けるための要点である。
4.1.1 広すぎるキャッチの危険
広範な捕捉は、本来の異常を別の挙動へ置き換えてしまい得る。結果として、重大な問題が軽微な扱いになり、後でより大きな障害として表面化する。
4.1.2 適切なスコープ設計
捕捉は必要最小限の領域に限定する。処理対象が明確なブロックに限定し、別の独立処理にまで影響が及ばないようにすることで、意図した復旧だけが実行される。
4.2 ロギングと監視
例外処理で重要なのは「起きたことを観測できる状態にする」ことである。ログは後から判断するための材料となる。
4.2.1 ログレベルの使い分け
例外を記録する際、重大度に応じてレベルを調整する。頻度が高い想定内の失敗まで高レベルで出すとノイズになり、重大な事象の発見が遅れる。逆に重大事象が低レベルだと見逃しが発生する。
4.2.2 スタックトレースの扱い
スタックトレースは調査に有用である。出力の粒度や保存方針は環境に合わせるが、少なくとも原因追跡に必要な情報が欠けないようにする。個人情報や秘匿データが混ざる場合はマスキングが必要になる。
4.3 トランザクション整合性
複数操作を含む処理では、途中失敗時に整合性を守る設計が不可欠である。例外処理はそのための制御点になる。
4.3.1 ロールバックのタイミング
ロールバックは、部分的に実行された変更を無効化する。タイミングを誤ると、失敗前の状態へ戻らずデータが中途半端になる。一般に、整合性が失われる前提が確立した時点で巻き戻しへ進む設計が求められる。
4.3.2 部分成功の設計
部分成功は、すべてを巻き戻すよりも現実的な場合がある。例えば独立したサブタスクのうち一部だけが完了するケースでは、成功分を確定し、失敗分を再処理へ回す、といった設計が行われる。ここでは「何を確定し、何を未確定とみなすか」という契約を明文化する。
4.4 パフォーマンスへの配慮
例外処理は常にコストを伴う。設計では、例外が制御フローの代わりになっていないかを点検する。
4.4.1 例外を制御フローに使わない
例外が通常の分岐手段として頻用されると、実行経路が読みにくくなり、最適化もしにくくなる。条件分岐や事前検証で済む部分はそちらに寄せ、例外は異常時のために温存するのが基本である。
4.4.2 再試行の上限と間隔
再試行には上限が必要である。無制限にすると障害が増幅し、間隔なしで行うと相手側にも負荷を与える。指数的な間隔設定や回数制御を取り入れ、復旧見込みと資源制約のバランスを取る。
5 テストと検証
例外処理はテストが重要である。なぜなら、通常経路ではほとんど顕在化せず、異常時の挙動はコード上の意図とズレやすいからである。
5.1 例外発生のテスト手法
例外が「適切な条件で」発生することを確認するには、観測可能な境界と入力設計が必要になる。
5.1.1 単体テストでの網羅
単体テストでは、事前条件の不成立、内部整合性の破壊、外部呼び出しの失敗など、想定される失敗要因を分解して検証する。モックやスタブを用いて、例外を確実に引き起こす状態へ誘導することが多い。
5.1.2 統合テストでの観測
統合テストでは、層をまたぐ伝播や変換、ログ出力、整合性の巻き戻しなどを観測する。特に、境界での責務分担が設計どおりかを重点的に確認する。
5.2 捕捉後の挙動確認
捕捉した後に、復旧経路が期待どおりに動くかが焦点となる。ここでは安全性と整合性が守られているかも含めて検証する。
5.2.1 復旧経路の検証
再試行、代替処理、中断の各経路について、期待される結果や通知が行われるかを確かめる。特に再試行では、回数や間隔の制約が正しく適用されるかが対象になる。
5.2.2 リソース解放の確認
例外発生後に資源が解放されるかを検証する。接続数の変化、ロック解除の有無、ファイルハンドルの残留など、直接観測できる指標を用いると効率的である。
5.3 回帰防止と品質指標
例外周りの変更は副作用が出やすい。継続的に品質を保つための指標と手法を用意する。
5.3.1 例外パターンのベンチマーク
既知の例外パターンを固定し、発生から捕捉、ログ記録、後処理完了までの挙動をベンチマークとして比較する。時間や回数の劣化も含めて追跡すると、改善の根拠が作りやすい。
5.3.2 変更時の影響範囲の把握
例外型の変更や変換ルールの更新は広範囲に波及することがある。どの層で捕捉され、どの経路で伝播するかを把握し、関連テストを選別して回帰のコストを抑える。
6 よくある誤り
例外処理の実装では、よく似た失敗パターンが繰り返される。典型例を把握して先回りすることが有効である。
6.1 例外の握りつぶし
握りつぶしは、例外が発生した事実を隠して処理を続けることで、調査と回復を難しくする。
6.1.1 “何も起きていないように見える”問題
例外が記録されないまま処理が続くと、ユーザーや呼び出し側は成功したように見える。後から不整合が顕在化し、原因が例外発生点と切り離されるため追跡が困難になる。
6.1.2 追跡不能になる原因
握りつぶしが起きる背景には、ログ不足や例外型の消失、スタック情報の欠落などがある。さらに、上位層へ引き継ぐ設計がない場合、責任の所在が不明になりやすい。
6.2 広範なキャッチによる事故
捕捉を安易に広げると、意図しない異常まで同じ扱いになる。これは事故の温床になる。
6.2.1 本来の異常を隠す
重大な失敗が軽微なものとして処理されると、システムは中長期的に不具合を抱え込む。結果として、より高いコストでの修正が必要になる。
6.2.2 障害解析の困難化
キャッチが広いと、どの失敗がどの箇所で発生したかの情報が薄れる。結果として、ログからの推定が難しくなり、復旧が遅れる。
6.3 例外に依存した設計
例外を設計の中心に据え過ぎると、通常経路が例外によって支配され、可読性と性能が悪化する。
6.3.1 戻り値や事前検証との役割分担
入力検証や事前条件の確認で防げるものまで例外へ押し込むと、頻度の高い失敗が例外として扱われる。結果として、分岐の意図が読み取りにくくなる。
6.3.2 パフォーマンス劣化
例外の生成やスタックトレース処理はコストになり得る。高頻度で発生する経路が例外頼みになると、全体の応答時間やスループットに影響が出る。
7 例外処理の小ネタと文化（軽い実装ネタ）
例外周りには、現場で語られる“あるある”や、合言葉のような定番表現が存在する。技術的な背景を保ったまま、チームの共通理解を作るのに役立つ。
7.1 「例外は去れ」系の定番フレーズ
「例外は去れ」は、乱用への戒めとして冗談めかして使われることがある。意図は、例外を通常制御の代替として使わず、異常時の伝達機構として扱えという注意喚起にある。言葉が強くても、設計の方向性が合っていれば価値がある。
7.2 デバッグ沼と例外のあるある
例外が起きたのに“原因が分からない”時間が長いのは、情報不足が原因であることが多い。例えば、メッセージが短い、文脈がない、ログが環境によって欠落していると、追跡は迷路になる。逆に、捕捉点で適切な要約をログに残し、スタック情報も保持しておくと、抜け出すまでの時間が短くなる。
7.3 失敗しないための心構え（紳士的なエラーハンドリング）
紳士的なエラーハンドリングとは、相手（利用者や呼び出し元）に無理をさせず、自分（システム）が壊れないように振る舞う姿勢である。具体的には、握りつぶさず、捕捉すべき箇所で判断し、回復不能なら安全に停止する。加えて、ユーザー向けには要点だけを示し、技術情報は適切な場所に記録する、というバランスが求められる。