Effective Java から例外関連項目

以下、『Effective Java (2nd Edition)』 から、9章「例外」に関係する項目。

緑：推奨 黄：注意 赤：禁止

Item 57: Use exceptions only for exceptional conditions
ループとかに使うなという基本中の基本。パフォーマンスにも悪影響あり。

Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
まあ一応、教科書的な原則としてはこんな感じだろう。ただチェック例外の是非については、結構物議を醸す。そもそも、こんなの必要なのかと。Spring なんかも RuntimeException 派だし、C＃や C++ でチェック例外が無いからといって困った事も全然ない。

Item 59: Avoid unnecessary use of checked exceptions
むやみにチェック例外を使うなと。例えば、「とりあえず呼んでみて例外が上がったらハンドリングする」なんてやり方より、「呼ぶ前にまずチェックする」やり方の方が、よりインテンショナルなコードになる場合がある。そんなメソッドのシグネーチャに例外を含めたって、誰の得にもならず負担が増えるだけ。

しかしここでも、いっそチェック例外なんて止めりゃいいじゃんなんて思いが、やはり沸いてきたりする…

Item 60: Favor the use of standard exceptions
例外に限らず全ての Java 標準APIに言えるけど、よく調べ、よく理解して、使い倒していくと、いろんな意味で効率的。低リスクで高い生産性が得られる。

Item 61: Throw exceptions appropriate to the abstraction
よくAPI なんかについて、低レベルとか高レベルとか言うけど、例外についてもレベルに合わせて使い分けよう、必要なら変換もしようという話。

Item 62: Document all exceptions thrown by each method
メソッドのドキュメントで、例外の説明をちゃんとしとけと。特に、RuntimeException だけで押し通す方針を選択した場合、チェック例外の面倒くささから解放される分、このドキュメント化だけはちゃんとしないと単なる手抜きになる。

Item 63: Include failure-capture information in detail messages
せっかく例外投げるんだから、ちゃんと原因究明の手がかりも含めようという、まっとうな話。まあ、面倒くさいし省かれがちだけど、これが正論。

Item 64: Strive for failure atomicity
例外送出による実行中断のおかげで、システムの状態が中途半端になったりしないように、例外発生時には呼び出し前の状態を復元しようという項目。

こういうのを考えると、注意喚起力が強いチェック例外って、やっぱアリかなあなんて思えてくる。少なくともドキュメントには、やはり可能性のある例外を列挙しておきたい。まあキャッチしたとしても、状態の復元はいつも簡単には行かないだろうけど。

Item 65: Don't ignore exceptions
これについては、前に書いた。驚くべき事に、例外を基底クラスでキャッチしてモミ消した挙句、鼻高々という面白い人種が、業界の底辺には多数棲息しているが、これらのおバカさん達についてもレポートした。