例外の扱いについてその２ - かとじゅんの技術日誌

さて、異論、奇抜論を唱えてみようかと思っているじゅんいち☆かとうですw

作者: Robert C. Martin,花井志生
出版社/メーカー: アスキー・メディアワークス
発売日: 2009/05/28
メディア: 大型本
購入: 27人クリック: 848回
この商品を含むブログ (66件) を見る

非チェック例外の章から紹介。
C#にはそもそも言語仕様としてチェック例外がない。C++にもない。Ptyhon, Rubyにもないが堅牢なアプリケーションが実装できる。後に登場した言語ではチェック例外がないことをよく考えてくださいとw。
デメリットとしてはキャッチから例外をスローするメソッドの間でオープンクローズド原則に違反してしまうことだそうだ。つまり、throwsのことを言及しているようです。これはアプリケーションが変更に対して弱くなりがちで、throwsの変更が発生すると下位（つまりスローするメソッド）から上位（つまりチャッチする処理）まで、その影響が伝播するのが一番のデメリット。あるケースにおいてはチェック例外は有効だが、ほとんどのアプリケーションの場合では非チェック例外の方が有益であると。
例外状況を回復できるチェック例外よりも、例外の仕様変更に影響を受けない非チェック例外が、有益性で勝るという言及。これがガツンときちゃった気がするw

そういえば、昔、.NETな友人がメソッドシグニチャからthrowsを廃止したのは、言語仕様として変更に強くなったので非常に評価できるといってたな。たぶん、Seasarで非チェック例外を扱っているのはこのためではないかと個人的に解釈しました。(ちなみに、T2のcommonsだけ見たのですが、非チェック例外をばりばり使ってますよね）
例外状況を回復することと、プログラミングエラーの立場だけで見ると、これはかなり強引に非チェック例外にしているように見えますが、例外の仕様変更に対しては強くなるわけです。要するに例外設計のYAGNI化ですw
C#はC++が系譜であったり、スクリプト言語であったりと比較対象としては難しいのですが、Javaの言語設計当時と、今では時代も変わってきていると思うので、上記のような知見はフレームワーク設計においては無視できないのだと思います。

おそらく、ある程度、変更に対する強さを犠牲にしても例外状況に対して回復できる方がよい場合はチェック例外を使ったほうがよいでしょうけど、実は今まで開発してて例外状況を回復させるという要求はほとんどなかった気がするんですよねー。それなら、変更コストが少ないほうがいいという考え方もある。CleanCodeで、ほとんどの場合では非チェック例外だといっているのはそのあたりのことかなーと思います。