まずは問題を見ろ
→ javadrill.tech で出題された問題を見る（Step08）
問題のポイント
- Javaの標準例外だけでは表現できない、**「アプリケーション特有のエラー」**を扱うには、独自の例外クラスを定義する必要がある。
- 例外は「システムが勝手に投げてくるもの」じゃない。
- 自分の文脈・自分のルールに従って、自分の例外を設計しろ。
まず、日本語で考えろ
「コード999は使っちゃダメ」
──これ、Javaの標準ライブラリには載ってないルールやろ？
だからこそ、「この状況はおれのアプリではNGなんです」と自分で意味をつけて投げる。
それが独自例外の出番や。
コメントを書け
// 業務ルールに違反するコードが入力された場合に例外を投げる
// MyAppException という独自の例外クラスを定義して使う
// 999が指定されたら MyAppException をスローするコメントに従ってコードを書け
// 独自例外クラス
public class MyAppException extends Exception {
public MyAppException(String message) {
super(message);
}
}// 業務ロジック側
public class ExceptionUtil {
public static void checkCode(int code) throws MyAppException {
if (code == 999) {
throw new MyAppException("コード999は使用できません");
}
System.out.println("コード: " + code);
}
}// 呼び出し元
public class Main {
public static void main(String[] args) {
try {
ExceptionUtil.checkCode(100);
ExceptionUtil.checkCode(999); // ← ここで独自例外がスローされる
} catch (MyAppException e) {
System.out.println("独自例外発生: " + e.getMessage());
}
}
}実行結果の例
コード: 100
独自例外発生: コード999は使用できませんコードの解説
MyAppExceptionはExceptionを継承したカスタム例外クラス- 業務ルール（ここではコード999禁止）を破ったときに
throw new MyAppException(...)を実行 - チェック例外なので、
throwsをつけて呼び出し元でtry-catchが必要 - 「コードの中に業務ルールを埋め込む」ことが可能になる構造
つまづきやすいポイント
Exceptionを継承するとチェック例外になる →throws宣言を忘れるとコンパイルエラーRuntimeExceptionを継承すれば非チェック例外になるが、それは別の場面で使う（後日）- 独自例外のメッセージは
super(message)を忘れずに書く
// tesh:
// 「独自例外？やりすぎじゃね？」
// ──そんなことはない。
//
// コードは意味を持つべきや。
// ルールがあるなら、それを名前付きの例外にして残すのが筋や。
//
// バグを追いかけるんじゃない。意味を構造に埋めろ。
//
// Just keep typing, baby.
// エラーに名前を与えろ。それはコードに文脈を与えることや。
