例外設計における大罪

例外設計における大罪

和田卓人 (a.k.a id:t-wada or @t_wada)Jun 27, 2012 @ java-ja

12年6月28日木曜日

自己紹介名前: 和田卓人 (わだたくと)

ブログ: http://d.hatena.ne.jp/t-wada

メール: [email protected]

Twitter: http://twitter.com/t_wada

タワーズ･クエスト株式会社取締役社長


http://d.hatena.ne.jp/t-wada

http://d.hatena.ne.jp/t-wada

mailto:[email protected]

mailto:[email protected]

http://twitter.com/t_wada

http://twitter.com/t_wada

よろしくおねがいします


例外設計における大罪


無視


public List<Entity> findByKeyword (String keyword)

throws Exception{ Connection conn = DriverManager.getConnection(...); PreparedStatement stmt = conn.prepareStatement( "SELECT * FROM Movie WHERE title LIKE ?"); stmt.setString(0, keyword); ResultSet rs = stmt.executeQuery(); List<Entity> entities = new ArrayList<Entity>(); while (rs.next()) { // ... } return entities;}


•例外処理を行わない言い訳

•コードの流れが追いにくくなる

•納期が迫っている

•エラーが戻ることが無い関数もある

•遊びで書いただけのプログラムだから…

きのこ93: エラーを無視するな


きのこ93: エラーを無視するな

•エラーを無視しても何も良いことは無い

•不安定なコード

•セキュリティ上問題のあるコード

•貧弱な構造とインターフェイス

•どうする?

•戻り値を使う

•例外を使う12年6月28日木曜日

隠蔽


“try-catchブロックをコードベースに大量に入れれば、「例外が発生しても絶対に止まらない」というアプリケーションを作ることが可能なはずです。ただ、これは、もう死んでいる人の体を釘か何かで固定し、無理矢理立った状態にしているようなものですが・・・。”

きのこ27: 死ぬはずのプログラムを無理に生かしておいてはいけない


} finally { if (rs != null) { try { rs.close(); } catch (SQLException e) { log.warn(e.getMessage(), e); } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { log.warn(e.getMessage(), e); } } if (con != null) { try { con.close(); } catch (SQLException e) { log.warn(e.getMessage(), e); } }}

遠い記憶

最近の Java に関しては try-with-resources で検索すべし12年6月28日木曜日

乱用


public int sum(List<Integer> toSum) {Iterator<Integer> iter = toSum.iterator();int sum = 0;try {while(true) {sum += iter.next();

}} catch (NoSuchElementException e) {}return sum;

}


•例外は、その名が示す通り、例外的条件に対してのみ使用するべきです。通常の制御フローに対しては、決して使用すべきではありません。

•上手く設計された API は、通常の制御フローに例外を使用することを、クライアントに強制してはなりません。

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


•「すべての例外ハンドラーを除去しても、このプログラムは動作することができるだろうか?」

•答えが「ノー」であれば、例外では無い状況下で例外が使われている

ヒント34: 例外は例外的な問題のみに使用すること


過剰防御


防御的プログラミングの是非


package javaja;

public class Defensive {private UserRepository userRepository;public Defensive(UserRepository userRepository) {

this.userRepository = userRepository;}

public User createUser(String name, int age) {if (name == null) {

throw new NullPointerException("name is null");}if (age < 0) {

throw new IllegalArgumentException("age is negative");}if (name.isEmpty()) {

throw new IllegalArgumentException("name is empty");}User user = this.userRepository.create(name, age);return user;

}}12年6月28日木曜日

package javaja;

public class UserRepository {public User create(String name, int age) {

if (name == null) {throw new NullPointerException("name is null");

}if (age < 0) {

throw new IllegalArgumentException("age is negative");}if (name.isEmpty()) {

throw new IllegalArgumentException("name is empty");}return new User(name, age);

}}


答えはあるのか


契約による設計

Design by Contract (DbC)


BertrandMeyer


•あるルーチン(注: メソッドと読み替えても良い)におけるすべての事前条件が呼び出し側によって満足された場合、そのルーチンは作業完了時にすべての事後条件とすべての不変表明を保証する

契約による設計Design by Contract (DbC)



•冗長性のある検証は実際損傷を与える

•システム全体の視点で見るとき、シンプルさ(simplicity)が重要になる

•複雑さは品質の敵である

•過剰に防御するのではなく、誰の責任なのかをはっきりさせる



•例外処理とは、予想外の実行時状態に対処するメカニズム

•失敗とは、ルーチンの実行で、契約を満足させられなくなること


•ルーチンはリトライ(Retry)か組織的パニック(Organized Panic)のどちらかで例外を処理する

•リトライとはルーチン本体を再び実行すること

•組織的なパニックはルーチンを失敗にして、そのルーチンを呼び出したものに例外を送る



おまけ12年6月28日木曜日

きのこ21: 技術的例外とビジネス例外を明確に区別する

•技術的例外とビジネス例外がある。これらを同じ例外階層構造に入れてはならない

•技術的例外は貫通させてフレームワークに任せる。ビジネス例外は準正常系なので呼び出し側で対処する


“「出来てはならぬことを禁じる」のではなく、はじめから「出来ていいことだけを出来るようにする」と考えるのです。”

きのこJ6: 見知らぬ人ともうまくやるには


Effective Java 2nd

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

•チェックされる例外を不必要に使用するのを避ける

•標準例外を使用する

•抽象概念に適した例外をスローする12年6月28日木曜日

Effective Java 2nd

•各メソッドがスローするすべての例外を文書化する

•詳細メッセージにエラー記録情報を含める

•エラーアトミック性に努める

•例外を無視しない


“チェック例外の代償は、開放/閉鎖原則に違反する点です”

=> 検索すれば良質の議論が読めます


まとめ12年6月28日木曜日

まとめ•例外処理/設計における大罪•無視•隠蔽•乱用•過剰防御•「契約による設計」がひとつの答え


名著を読もう!


ご清聴ありがとうございました


例外設計における大罪

Technology