📖

例外について学んでみた

に公開
アーキテクチャ
設計
エラーハンドリング
例外処理
ドメイン駆動設計（ddd）
idea

例外の正しい理解と分類 —— 技術的例外・ビジネス的例外・Expected/Unexpected

🎄　この記事は （TechBull アドベントカレンダー 2025（3日目））の記事です。

この記事では、ソフトウェア開発における「例外」について整理し、
技術的例外／ビジネス的例外／予期する例外／予期しない例外 の4つの観点で解説します。

📝 このテーマを選んだきっかけ

直近の業務タスクで、エラーハンドリング内の例外処理方針に悩むことがありました。
同期に相談する中で「そもそも例外の分類や扱い方についての理解が曖昧かもしれない」と気づき、
この機会に体系的に学び直してみようと思ったことがきっかけです。

例外は大きく4種類に分類できる

  1. 技術的例外（Technical Exception）
  2. ビジネス的例外（Business Exception）
  3. 予期する例外（Expected Exception）
  4. 予期しない例外（Unexpected Exception）

※ 技術的例外／ビジネス的例外は「性質」に基づく分類、
Expected／Unexpected は「扱い方」に基づく分類であり、補完関係にあります。

1. 技術的例外（Technical Exception）

技術的例外とは、プログラムの技術的な問題が原因で発生する例外です。
発生するとアプリケーションの正常実行が困難になるタイプの例外を指します。

例：

  • Null参照
  • ネットワーク断
  • DBサーバの停止
  • 配列範囲外アクセス など

✔ なぜ「自分で細かい例外処理を書かない方がよい」のか？

技術的例外に対して、メソッド単位で細かく例外処理を書くことは推奨されません。

理由：

  • 開発者が局所的に対応しようとすると、
    逆に 問題を握りつぶして全体の挙動を不安定にする可能性がある。
  • この種の例外は、多くの場合「復旧不能」または「局所で対処不能」。
  • トップレベルの例外ハンドラに任せた方が安全で一貫性がある。

トップレベルでは、以下のような処理が体系的に行われます。

  • トランザクションのロールバック
  • エラーログの記録
  • 監視システムへの通知
  • ユーザー向けのエラーメッセージ表示

これらは個々のメソッドで行う性質の処理ではありません。

✔ ライブラリ利用時の技術的例外

ライブラリの Contract（契約）を破った場合も、技術的例外が発生します。
例えば不正な引数や不整合な状態で呼び出した場合などです。

この場合も、

  • 呼び出し側が事前チェックする
  • 契約違反が起こった場合はそのまま例外を上位に投げる

というのが一般的に推奨されるスタイルです。

2. ビジネス的例外（Business Exception）

ビジネス的例外は、アプリケーションのドメインルールに起因する例外です。
ユーザーの操作や入力がビジネスルールに違反した場合に発生します。

例：

  • 注文数量がマイナス
  • 在庫数を超える購入リクエスト
  • 予約可能期間外の操作
  • ログイン試行回数の上限超過

これらは、

  • アプリケーションが 予期できる
  • ユーザーに正しい操作を促すことで 解決できる

という点で、技術的例外とは明確に異なります。

3. 予期する例外（Expected Exception）

予期する例外とは、発生が事前に想定されており、正常系の一部として扱うべき例外のことです。

✔ 典型的な例

  • ユーザー入力の不備（フォーマット違い・必須項目なし）
  • ネットワークタイムアウト
  • ファイルが存在しない
  • 外部APIがバリデーションエラーを返す

✔ 特徴

  • 発生が予測可能
  • ビジネスロジック上の「想定された失敗」
  • ハンドリング方法が明確（リトライ、UIメッセージ、フォールバックなど）
  • ログレベルは INFO または WARNING

✔ 扱い方

  • 明示的に catch する
  • ユーザー向けにわかりやすいエラーメッセージを返す
  • 再発を前提に設計（リトライ戦略・フォールバックなど）

4. 予期しない例外（Unexpected Exception）

予期しない例外とは、開発者が想定していない状態で発生する例外です。
多くはアプリケーションのバグや異常状態が原因です。

例：

  • NullPointerException（想定外の null）
  • ゼロ除算
  • 想定外フォーマットのデータ混入
  • 設計上ありえないはずの状態遷移

✔ 特徴

  • 事前にハンドリング方針がない
  • プログラムのバグが主原因
  • 回復が困難（続行すると危険）
  • ログレベルは ERROR または FATAL

✔ 扱い方

  • 全体の例外ハンドラで集約して処理
  • 詳細なログを残す
  • デバッグや根本原因の修正が必須

まとめ

種類 内容 主な原因 どう扱う？
技術的例外 技術起因の障害 ネットワーク断・Null参照など トップレベルに委譲
ビジネス的例外 ドメインルール違反 不正入力・業務ルール違反 明示的にハンドリング
予期する例外 想定された失敗 入力エラー・外部APIバリデーション ハンドリングと回復処理
予期しない例外 想定外の状態 バグ・異常状態 全体ハンドラで集約処理

例外設計は「何を局所で処理すべきか」「何を上位に投げるべきか」を見極める重要な要素です。
理解が深まることで、堅牢で保守しやすいアプリケーション設計につながります。

📚 参考文献

例外設計について理解を深める際に参考にした資料を紹介します。
どれも実務に役立つ内容なので、興味があればぜひチェックしてみてください。

よければ、X（@ninomin_tech）や
個人ブログ（ninominlog.com）もチェックいただけると嬉しいです！

Discussion