Throwableについて本気出して考えてみた 2nd Season - 都元ダイスケ IT-PRESS
1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例
バグ発生時に投げるべき例外 - 都元ダイスケ IT-PRESS
「メソッドを呼ぶ前提条件が間違っている（ユーザによるミス）」時の例外は、IllegalStateExceptionですよね。そして「引数が間違ってる（ユーザミス）」時はIllegalArgumentException。 しかし「バグが発生した（API提供側のミス）」時に投げるべき例外って、何がいいんでしょう？ 例えば「ここには絶対到達しない、ホントは」って場所に書いておくもの。 Effective Java 第2版 (The Java Series)だと、そういったポイントでは AssertionError を投げていますが、Errorを投げるって邪悪じゃねーかなぁ…ｗｗ しかも、AssertionError って assert文の評価失敗の時に投げられるものですよね。VMの起動引数に -ea が付いていないときは、むしろ「投げちゃいけないモノ」なんじゃないかな、と…。 さてさて…。単純に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
