1. Effective Java 輪読会
2014/02/26
開発部 田中

2. 項目57
例外的状態にだけ例外を使用する

3. try-catchはいつ使うべきか
• 例外的条件でのみ使われるべき
o 通常の制御フローで例外を使うと可読性を下げる
try {
int i = 0;
while(true)
range[i++].climb();
} catch (ArrayIndexOutOfBoundsException e) {
}
for (Mountain m : range) {
m.climb();
}

4. これに対する我々の答えは、「例外とは予期せぬ
事態に備えるためのものであり、プログラムの通
常の流れの一部には組み込むべきではない」とい
うものです。例外がプログラム中で捕捉されな
かった場合、そのプログラムは停止します。この
ような前提を置いた上で、「すべての例外ハンド
ラーを除去しても、このプログラムは動作するこ
とができるだろうか？」と自問してください。答
えが「ノー」であれば、例外ではない状況下で例
外が使われているはずです。
達人プログラマー 24 いつ例外を使用するか

5. API設計も意識する
• IteratorにhasNextメソッドがない場合..
o 要素がなくなったことをcatchしなければならない
 状態検査メソッドが必要
try {
Iterator<Foo> i = collection.iterator();
while(true) {
Foo foo = i.next();
}
} catch (NoSuchElementException e) {
}

6. 状態検査メソッド | 区別できる戻り値
• 使い分けの目安
a. 同期なし並行アクセスされるか、外部要因で状態遷
移する場合：状態遷移メソッド
b. 状態に依存したメソッドの処理を重複して行う必要
がある場合：区別できる戻り値（かも）

7. 項目58
回復可能な状態にはチェックされる例外を、
プログラミングエラーには実行時例外を使用
する

8. Javaの例外
• Javaの例外3種類
a. チェック例外
b. 実行時例外
c. エラー
• Throwable
o Error
o Exception
 RuntimeException

9. チェック例外 | 実行時例外
• 呼び出し側で適切に処理（回復）可能なら
チェック例外を使用するべき
• 事前条件違反（クライアント側の債務不履
行）になる場合、実行時例外がスローされ
るべき
• ErrorはJVMに予約されている慣例がある
o 実装しない
• それ以外の独自例外はAPIを複雑にするだけ

10. 項目59
チェックされる例外を不必要に使用するのを避
ける

11. チェック例外が本当に必要か考慮する
• チェック例外は、例外を更にスローするか、
クライアントコードで捌くことを強制する。
o 開放－閉鎖原則に違反
o クライアントコードが複雑になりがち
o チェック例外を避ける方法がないかを考える
 try-catch → if-else

12. try-catch → if-else
try {
FileInputtream fin = new FileInputStream(“hoge.txt”);
...
} catch (FileNotFoundException e) {
...
}
FileInputStream2 fin = new FileInputStream2(“hoge.txt”);
if (fin.tryOpen()) {
...
} else {
...
}

13. チェック例外の必要性

14. 契約による設計
• 「あるルーチンにおけるすべての事前条件
が呼び出し側によって満足された場合、そ
のルーチンは作業完了時にすべての事後条
件と全ての不変表明を保証する。」
• 「失敗とは、ルーチンの実行で、契約を満
足させられなくなること」

15. つまり
「例外は呼び出す側が契約条件を満たしたが、
呼び出された側が契約を履行できなかった時
に投げるもの」

16. 開放－閉鎖原則に違反する可能性
まず、検査例外は発生したその場、もしくは直接
の呼出し元で処理しない限り、throws に記述せざ
るを得ない。
そうしない場合、より上位層の throws を追加する
必要が出てくる。このような追加、もしくは変更
は、中間のクラスの再リリースという手間も必要
となる。
これは、明らかに開放－閉鎖原則に違反する。

17. 開放－閉鎖原則
モジュールは、 「拡張」に対して開いており、
「修正」に対して閉じていなければならない。
モジュールは、変更容易性がどの部分にあるのか
を考慮して、設計されなければならない。
それにより、仕様変更時に「修正」による変更
（デグレ）を行わずに、「拡張」による安全な変
更を行うことができる、ということ。

18. DataSpider では..

19. まとまらない結論
• チェック例外は、開放－閉鎖原則に違反す
る使い方もできるが、即チェック例外を使
用すべきとは判断できない。