「検査例外はアジャイルやオブジェクト指向の考えに反するという事実」について一部誤解あり - かとじゅんの技術日誌
追記： id:Nagiseさんからエントリいただきました。 というわけで、ややしつこく感じられるかもしれないけど誤りだと思うところはツッコミを入れさせてもらいます。人に恨みがあるとかそういうわけじゃなくて、説に用事があるってところをご理解いただければ幸いです。 こちらも建設的な議論をしたいと思っているので、もちろん、そのつもりです。 中間のクラスが〜という話題は、開放閉鎖原則を破って境界面に変更を加えた場合に話であって、検査例外が開放閉鎖原則を破るわけじゃない。 なるほど。よくわかりました。 目的と手段で分離してみた場合、「開放閉鎖原則」を「検査例外」を使って破っているだけであって「検査例外」自体の存在が「開放閉鎖原則」を破っているわけでない。「開放閉鎖原則」を破るのは「非検査例外」でもできるわけで、直接の因果関係は成立しないということですね。これは、私の論じ方に問題あったようです。ここに
非チェック例外多用作戦のトレードオフ認識 - 都元ダイスケ IT-PRESS
まず、以下に持論を展開するにあたって、自分の立ち位置を明確にしよう。自分は「Webアプリケーション開発者」としてではなく「JavaによるWebアプリではない（デスクトップアプリ,コマンドラインアプリ,ライブラリ）アプリの開発者」として語る。まぁ、自分に一番馴染みの深いプロダクトとしてJiemamyが挙げられるわけだが、こいつはWebアプリじゃない。Eclipse上で動くアプリケーションであり、そしてMaven2によって呼ばれるCLIアプリでもあり、また、クラスライブラリである。 この視点からJavaにおけるチェック例外と非チェック例外の話を再び。 Javaにおけるthrows句は、メソッドシグネチャの一部であり、インターフェイスにも現れる情報である。今まで「Javadocは仕様だ」と言い続けて来たが、正確にはインターフェイス（シグネチャ＋Javadoc）が仕様だ。*1 検査例外が使いにくい
検査例外と非検査例外(実行時例外)をどう使い分けるか - Masa / Lino Blog
とある後輩が執拗に検査例外と非検査例外の使い分けについて聞いてくるので、久しぶりに真面目な話を書いてみます。 最初は一般的なJava言語的な解釈。 Effective Java的には次のようなベストプラクティスが書かれています。 40項: 回復可能な条件にはチェック済み例外を、プログラミング・エラーにはランタイム例外を使う。 Effective Java プログラミング言語ガイド 後者の「プログラミング・エラーにはランタイム例外を使う」っていう部分は、NullPointerExceptionとかの実行時例外は呼び出す側の頑張りで回避可能ということで非検査例外で処理するべきだよってことでしょう。 一方前者の「回復可能な条件にはチェック済み例外を」の部分ですが、回復可能な条件であればその通りだと思います。 ちなみにJava SEでは回復不可能でもSQLExceptionやFileNotFoun
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
