例外設計における大罪

例外設計における大罪和田卓人 (a.k.a id:t-wada or @t_wada) Jun 27, 2012 @ java-ja12年6月28日木曜日

自己紹介名前: 和田卓人 (わだたくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ･クエスト株式会社取締役社長12年6月28日木曜日

よろしくおねがいします12年6月28日木曜日

例外設計における大罪12年6月28日木曜日

無視12年6月28日木曜日

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;}12年6月28日木曜日

きのこ93: エラーを無視するな • 例外処理を行わない言い訳 • コードの流れが追いにくくなる • 納期が迫っている • エラーが戻ることが無い関数もある • 遊びで書いただけのプログラムだから…12年6月28日木曜日

きのこ93: エラーを無視するな • エラーを無視しても何も良いことは無い • 不安定なコード • セキュリティ上問題のあるコード • 貧弱な構造とインターフェイス • どうする? • 戻り値を使う • 例外を使う12年6月28日木曜日

隠蔽12年6月28日木曜日

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

} 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日木曜日

乱用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; }12年6月28日木曜日

項目57: 例外的状態にだけ例外を使用する• 例外は、その名が示す通り、例外的条件に対してのみ使用するべきです。通常の制御フローに対しては、決して使用すべきではありません。• 上手く設計された API は、通常の制御フローに例外を使用することを、クライアントに強制してはなりません。12年6月28日木曜日

ヒント34: 例外は例外的な問題のみに使用すること• 「すべての例外ハンドラーを除去しても、このプログラムは動作することができるだろうか?」• 答えが「ノー」であれば、例外では無い状況下で例外が使われている12年6月28日木曜日

過剰防御12年6月28日木曜日

防御的プログラミングの是非12年6月28日木曜日

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); }}12年6月28日木曜日

答えはあるのか12年6月28日木曜日

契約による設計 Design by Contract (DbC)12年6月28日木曜日

Bertrand Meyer12年6月28日木曜日

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

契約による設計 Design by Contract (DbC)• 冗長性のある検証は実際損傷を与える• システム全体の視点で見るとき、シンプルさ(simplicity)が重要になる • 複雑さは品質の敵である• 過剰に防御するのではなく、誰の責任なのかをはっきりさせる12年6月28日木曜日

契約による設計 Design by Contract (DbC)• 例外処理とは、予想外の実行時状態に対処するメカニズム• 失敗とは、ルーチンの実行で、契約を満足させられなくなること12年6月28日木曜日

契約による設計 Design by Contract (DbC)• ルーチンはリトライ(Retry)か組織的パニック(Organized Panic)のどちらかで例外を処理する • リトライとはルーチン本体を再び実行すること • 組織的なパニックはルーチンを失敗にして、そのルーチンを呼び出したものに例外を送る12年6月28日木曜日

12年6月28日木曜日

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

きのこ21: 技術的例外とビジネス例外を明確に区別する• 技術的例外とビジネス例外がある。これらを同じ例外階層構造に入れてはならない• 技術的例外は貫通させてフレームワークに任せる。ビジネス例外は準正常系なので呼び出し側で対処する12年6月28日木曜日

きのこJ6: 見知らぬ人ともうまくやるには「出来てはならぬことを禁じる」のではなく、はじめから「出来ていいことだけを出来るようにする」と考えるのです。12年6月28日木曜日

Effective Java 2nd • 回復可能な状態にはチェックされる例外を、プログラミングエラーには実行時例外を使用する • チェックされる例外を不必要に使用するのを避ける • 標準例外を使用する • 抽象概念に適した例外をスローする12年6月28日木曜日

Effective Java 2nd • 各メソッドがスローするすべての例外を文書化する • 詳細メッセージにエラー記録情報を含める • エラーアトミック性に努める • 例外を無視しない12年6月28日木曜日

チェック例外の代償は、開放/ 閉鎖原則に違反する点です => 検索すれば良質の議論が読めます12年6月28日木曜日

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

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

名著を読もう!12年6月28日木曜日

ご清聴ありがとうございました12年6月28日木曜日

http://d.hatena.ne.jp	1256
https://twitter.com	263
http://grimrose.blogspot.jp	241
http://157.109.200.99	229
http://bikkuri.me	121
http://blog.livedoor.jp	55
http://grimrose.blogspot.ru	48
http://us-w1.rockmelt.com	27
http://tweetedtimes.com	20
http://nuevospowerpoints.blogspot.com	16
http://157.109.200.99:8090	11
http://157.109.86.99	8
http://nuevospowerpoints.blogspot.com.ar	6
http://s.deeeki.com	5
http://favtile.com	5
http://grimrose.blogspot.com	4
http://nuevospowerpoints.blogspot.com.es	4
http://yana.hatenablog.com	3
http://nuevospowerpoints.blogspot.mx	2
http://b.hatena.ne.jp	2
http://twitter.com	1
http://mundo-powerpoints.blogspot.com	1
http://mundo-powerpoints.blogspot.com.ar	1
http://localhost	1

例外設計における大罪

by Takuto Wada on Jun 27, 2012

Accessibility

Categories

Upload Details

Usage Rights

24 Embeds 2,330

Statistics

例外設計における大罪 Presentation Transcript