もっと知りたい！じっくりプログラミング講座（中級者編）第4回：例外処理の設計
はじめに
さあ、第4回の講座の内容にまいりましょう。プログラムというものは、思いどおりに動いているときだけが本番ではございません。予期せぬ事態にどう向き合うか——その設計こそが、コードの品格を決めるものでございます。例外処理は「エラーが起きたときの対処」と軽く見られがちですが、実はシステム全体の信頼性を支える、とても奥深いテーマです。今回は、その本質をしっかりと味わっていただけますよう、丁寧にお伝えしてまいります。
サマリ
例外処理は「エラーが出たら catch する」だけではございません。どの層で例外を捕捉するか、どんな例外クラスを設計するか、そしてログや通知をどう組み合わせるか——これらを体系的に考えることで、保守性と信頼性の高いシステムが生まれます。この回では、例外処理を「設計」として捉える視点をしっかり身につけていただきます。
詳細
例外処理を「設計」として捉える
多くの中級者の方が、例外処理を「エラーが出たときに書き足すもの」と感じていらっしゃるかもしれません。しかし本来、例外処理はシステム設計の段階から考えるべき要素です。
「どこで何が失敗しうるか」を事前に洗い出し、それぞれに対して適切な対応策を用意しておく——この思考の流れが、例外処理設計の出発点となります。
事後的に付け足された例外処理は、往々にしてコードの見通しを悪くしてしまいます。最初から設計に組み込むことで、コードはぐっとすっきりいたします。
例外クラスの設計と階層化
汎用的な例外クラスをそのまま使うだけでは、エラーの原因が曖昧になってしまいます。たとえば「エラーが起きた」という情報だけでは、それがネットワーク障害なのか、データ不正なのか、権限の問題なのかが判断できません。
そこで有効なのが、例外クラスの階層化です。基底となる例外クラス（例：アプリケーション独自の基底例外）を定義し、そこから「データベース例外」「外部サービス例外」「バリデーション例外」などを派生させる構造が、実務ではよく用いられます。
こうすることで、`catch` する側が例外の種類に応じた処理を書きやすくなり、ログの分析も格段に楽になります。
例外を捕捉する層をどこに置くか
例外処理設計でよく議論されるのが、「どの層で例外を捕捉するか」という問題です。発生した場所のすぐそばで捕捉すべき場合もあれば、上位レイヤーに伝播させてまとめて処理すべき場合もあります。
基本的な考え方として、「その層で意味のある対応ができるかどうか」が判断の軸になります。たとえばデータアクセス層では、接続エラーをリトライする処理は書けます。しかし「ユーザーにエラーメッセージを表示する」という判断は、プレゼンテーション層の責務です。
例外を無闇に飲み込んで握りつぶす実装は、バグの原因を隠蔽してしまうため、大変危険でございます。捕捉するならば、必ず何らかの意味ある処理を伴うようにしましょう。
ログと例外の連携設計
例外が発生したとき、それをどのようにログへ記録するかも重要な設計要素です。スタックトレースだけを残すのか、発生時のコンテキスト情報（ユーザーID・リクエスト内容など）も含めるのかによって、後の調査のしやすさが大きく変わります。
実務では、ログのレベル（情報・警告・エラー・致命的）を例外の重篤度と対応させておくと、監視ツールとの連携がスムーズになります。すべての例外を同じレベルで記録してしまうと、本当に重要なアラートが埋もれてしまいます。
「何が起きたか」だけでなく「なぜ起きたか」を追跡できるログ設計を心がけてみてください。
チェック例外と非チェック例外の使い分け
言語によっては、チェック例外（コンパイル時に処理を強制される例外）と非チェック例外（実行時例外）が区別されています。代表的な例はJavaですが、この使い分けは設計思想と深く結びついています。
チェック例外は「呼び出し元が必ず対処すべきエラー」に用いるのが原則です。ファイルの読み込み失敗や外部APIの呼び出し失敗などが該当します。一方、プログラムのバグに起因するもの（ヌルポインタや配列の範囲外アクセスなど）は、非チェック例外として扱うのが一般的です。
この境界線を意識して設計することで、APIの利用者にとって使いやすく、意図が明確なインターフェースを提供できます。
おわりに
例外処理は、コードが「想定内の世界」を超えたときに初めてその真価を問われるものでございます。普段は表に出てこないからこそ、丁寧に設計されているかどうかが、システムの底力に直結するのです。今回ご紹介した考え方を、ぜひ日々のコーディングの中で少しずつ取り入れてみてくださいませ。次回はいよいよ「アルゴリズムの基礎」をご一緒に学んでまいります。どうぞ楽しみにお待ちくださいね。
