それが例外なのかどうかを判断するのはクライアント側ではないのか、という
http://www.kmonos.net/wlog/88.html#_2233080818を見て思いついた話(ぬるぽとは関係ないけど、Integer.valueOf的な処理のエラー処理の別アプローチとして。)
エラーを返すか例外を返すか。
「例外」かどうかを決めるのは誰なのか、という。
辞書にキーがあることをユーザが確信しているかの問題。確信してたら例外だしないかもと思ってたらnullが返ってほしい。
「例外を投げる」インタフェースと「失敗という値を返す」インタフェースを、すべての「ユーザが失敗を予期できる」処理に対して用意する方法。
例外は例外的な状況で使うべしという原則を徹底すると、catchすべき例外はほとんど設計ミス？少なくとも、parseIntの例外をキャッチしてフォーマットエラー補足なんてのはひどい。
tryブロックに一行しか書いてないのは特におかしい。
ソリューション。
「ユーザが予期しているなら、それはチェックされているはずである」
ユーザはその呼び出しが失敗する可能性を予期しているか?
エラーチェックされてるなら、エラーかどうか示す値を。
チェックされてなかったら、例外を。
前にC++で、例外かどうかをユーザの行動で判断するクラスを作った。
暗黙のエラーチェックを実現する - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥に作りかけのやつが置いてある*1。この例はちょっとトリッキーかつ不完全なんだけど、基本思想は「ユーザがエラーチェックしないのは、エラーを想定していないから」。チェックされないエラーは例外だし、チェックされたエラーは例外ではない。
もっと発展したバージョンを整数をパースする例に適用すると、こんなかんじ。
//パースに成功することを確信している場合 string just_number="1000"; result<int> r=parse_int(just_number); //パースに失敗していたら、r.value()の呼び出しで例外が飛ぶ cout << "the number is " << r.value() << endl; //パースに失敗する可能性を認識している場合 string various_characters="a10923k8&^wtf(*"; result<int> r=parse_int(various_characters); if(r) { //parse success cout << "the number is " << r.value() << endl; } else { cout << "parse err: " << r.message() << endl; }
例外の意味をよく考えると、投げられた例外をキャッチするってかなり特殊なことに思える。失敗を想定してない処理が失敗したから例外なのに、最初からそれに備えて回復処理してしまうとはこれいかに。それ例外じゃないだろと。
ある処理の失敗が例外かどうかユーザが明示的に指定できる言語というのはどうだろう。
var num1=parseInt("hoge"); //throws exception var num2=@parseInt("hoge"); //num2==null
@はPHPのエラー制御演算子(あれはひどい)からのインスパイア。
(散漫なまま終わる)
ref
- 今週のクラス System.Exception むやみに例外をキャッチするな、という話
