はじめに
この記事では、カスタム例外を使う本質的な理由を、
- 「どの例外で何をすべきかを明確にする」
- 「ログ・UI・通知の制御を型で分離する」
という視点から整理する。
例外処理が曖昧だと、何が問題になるのか？
すべての例外を Exception で処理したコード
try {
// 何かの処理
} catch (Exception $e) {
logError($e->getMessage());
echo "エラーが発生しました";
}
この場合、発生した例外が「入力ミス」なのか、「システム障害」なのか、「外部APIの失敗」なのかが曖昧。
その結果、以下のようになる。
- すべて同じログレベルで記録される
- エラーメッセージの内容に頼って分岐しようとする
カスタム例外を使うことで「何をすべきか」が明確になる
例外ごとに意味を持たせてクラスを分けることで、次のように意図を明示できる。
class ValidationException extends Exception {}
class DatabaseConnectionException extends Exception {}
try {
// バリデーション or DB接続処理
} catch (ValidationException $e) {
logWarning($e->getMessage());
echo "入力内容に誤りがあります";
} catch (DatabaseConnectionException $e) {
logError($e->getMessage());
notifyAdmin($e);
echo "システムエラーが発生しました";
}
このようにすることで、例外の種類ごとに処理を整理・分岐できるようになる。
例外ごとに「やるべきこと」は違う
| 例外クラス | 何が起きたか | 何をすべきか |
|---|---|---|
ValidationException |
入力内容に問題がある | ユーザーにエラーメッセージを表示＋warningログ |
AuthenticationException |
認証情報が不正 | ログイン画面に遷移＋infoログ |
DatabaseConnectionException |
DBが落ちている、接続できない | errorログ＋Slack通知＋再接続リトライ |
Throwable（その他） |
想定外のバグやエラー | criticalログ＋500エラー画面＋運用対応 |
これが、「例外とはただのエラーではなく、意味のあるイベント」である、という考え方。
まとめ
単に動けば良いと考えるのではなく、「例外をどう扱うか」を考えることが重要。
- どの例外が起きたら、何をすべきか？
- 誰に通知し、どのログに残し、どのようなUIやレスポンスにするか？
これを明確にできる設計が、カスタム例外の本当の価値。