🚨
Javaの例外処理：基本と体系的な整理
✅ Javaの例外処理 概要まとめ
1️⃣ レガシー方式の例外処理（昔のやり方）
- 条件文（
if）で1つずつチェックしてエラーを処理 - 例外が発生しても
throwを使わず、直接メッセージを出力 - コードが長くなり、
if文のネストで可読性が悪化 - 保守性が低い
2️⃣ OOP方式の例外処理（オブジェクト指向）
- 条件を関数に分け、問題があれば
throwで例外を投げる - 呼び出し元では
try-catchでまとめて処理 - 可読性・保守性・再利用性が向上
✅ Checked例外 vs Unchecked例外
| 分類 | Checked Exception | Unchecked Exception |
|---|---|---|
| 意味 | コンパイル時に処理が強制 | コンパイル時の処理は任意 |
| 例 |
IOException, SQLException
|
NullPointerException, ArithmeticException
|
| 発生原因 | 外部リソースの問題（ファイル、DBなど） | 開発者のミスや論理エラー |
| 処理方法 | 必ず throws または try-catch が必要 |
処理しなくてもコンパイル可能 |
| 親クラス | Exception |
RuntimeException |
✅ Errorはどこに分類される？
-
ErrorはExceptionではない →Throwableの別の子クラス -
復旧不可能なシステムエラー（例：
OutOfMemoryError,StackOverflowError） -
try-catchで捕捉することは可能だが、基本的には推奨されない - 発生するとプログラムはそのまま終了する
✅ 全体の階層構造まとめ
Object
└── Throwable
├── Exception ← 復旧可能（例外処理対象）
│ ├── Checked ← try-catch または throws が必要
│ └── Unchecked ← コンパイラの強制なし
└── Error ← 復旧不可能、処理は非推奨
✅ 全体まとめ
最初はレガシー方式で if 文を使って例外処理をしていたが、
コードが長くなり、可読性も悪く、保守もしづらかった。
その後、OOP方式に切り替え、throw で例外を発生させ、
try-catch で一括して処理することで構造がすっきりした。
例外は Checked と Unchecked に分かれ、
Checked は必ず例外処理が必要、
Unchecked は実行時に発生するため任意で処理できる。
さらに Error は復旧できないシステムレベルの例外であり、
多くの場合プログラムは強制終了する。
Discussion