なぜ「Exceptionメッセージ取得ユーティリティ」が業務で役に立つのか
業務システムでは、例外が発生したときに「何が問題だったのか」を分かりやすく伝えることがとても重要です。 ログに残すときも、画面にエラーメッセージを表示するときも、通知メールを送るときも、最初に頼りになるのは Exception のメッセージ です。
しかし、実務で例外を扱っていると、次のような悩みが出てきます。
e.getMessage()がnullのことがある- ラップされた例外（原因を内包した例外）の「本当の原因メッセージ」を取り出したい
- ユーザー向けには優しいメッセージ、ログ向けには詳細なメッセージを使い分けたい
- セキュリティ的に「外部には出したくない情報」を含むメッセージをそのまま出したくない
そこで、「Exceptionメッセージ取得ユーティリティ」を用意しておくことで、 どの機能からも同じルールで、分かりやすく・安全に・再利用しやすく例外メッセージを扱えるようになります。
ここから、プログラミング初心者向けにステップバイステップで考えながら、 実務で使える Exceptionメッセージ取得ユーティリティを丁寧に解説していきます。
ステップ1 Exceptionメッセージの基本を理解する
getMessage() は「例外が伝えたい一言」です
まず、Java の例外クラスには getMessage() というメソッドがあります。 これは、その例外が「何を伝えたいか」を表す短いテキストです。
例えば、次のようなコードを考えます。
public class ExceptionMessageBasicExample {
public static void main(String[] args) {
try {
throw new IllegalArgumentException("不正なパラメータです");
} catch (Exception e) {
System.out.println("getMessage(): " + e.getMessage());
}
}
}
この場合、出力は次のようになります。
getMessage(): 不正なパラメータです
ここで押さえておきたいのは、 「getMessage() は人間が読んで意味が分かるように書くべきもの」 ということです。 業務システムでは、開発者だけでなく運用担当者やサポート担当者もこのメッセージを見ることがあります。
ステップ2 ラップされた例外（cause）を意識する
「表面の例外」と「本当の原因」が分かれていることが多いです
実務では、例外をラップして投げ直すことがよくあります。 例えば、次のようなコードです。
public class WrappedExceptionExample {
public static void main(String[] args) {
try {
lowLevel();
} catch (Exception e) {
throw new RuntimeException("ユーザー更新処理でエラー", e);
}
}
static void lowLevel() {
throw new IllegalArgumentException("IDが不正です");
}
}
ここで最終的に捕まえる例外は RuntimeException ですが、 その「原因（cause）」として IllegalArgumentException が内包されています。
Throwable には getCause() というメソッドがあり、 これをたどることで「本当の原因メッセージ」にたどり着くことができます。
Throwable root = e;
while (root.getCause() != null) {
root = root.getCause();
}
System.out.println("root message: " + root.getMessage());
このように、「表面の例外」と「根っこの例外」が分かれていることを意識しておくと、 例外メッセージ取得ユーティリティの設計が明確になります。