自分にとってこの話題は大変難しく感じるので不十分かも知れないと思いつつコメントを試みます。
関数のネスト元までソースレベルで確認するしかないのでしょうか?
申し訳ないですがRubyやPHPのライブラリーのドキュメントの実体を自分は知りません。しかし一般論(理想論)として信用に足るまっとうなライブラリーなのであれば関数が発する可能性がある例外は各々の関数の仕様(リファレンス)に書かれているべきと考えます。従ってある関数Fの実装者は自分の実装で発生する可能性のある例外は「自分が直接呼び出している関数のドキュメントから列挙できるべき」と考えます。そうなっていないなら高度な機能を持つライブラリーを使うアプリケーションを充分信頼に足るように設計するのは大変困難になると思います。一般に公開されているライブラリーであればしかるべきドキュメントが整備されていることが多いと思いますが、逆に自分が他チームと共同で開発したりすることを想定するとそのようなドキュメントがきちんと残せるかといえば・・・難しい(または大変な困難・苦痛を伴う)のではないかとも感じます。
関数αを使いたい場合、実質関数aが発生させる例外を関数αを使う側のコードに書いてやらなければいけない
質問者さんがこの文に込められている意図が自分には充分想定できないので的外れなことを言うかもしれませんが、「そこは違うのでは?」と感じました。(以下に書いたことをご覧になって「いやそういうことをいいたいのではなくて・・・」と思われるかもしれません。そのときは読み飛ばしていただきたいと思います。)
ある関数Fを設計する際、関数を使う側(caller)としてのFが自分が呼び出す関数(callee)に対して例外処理を行うべきかどうかはFの役割によると思います。
Fもまた他の関数から呼び出される立場であることが一般的と思います。よってFは自分の利用者に対して「Fがどんな例外を発するかを明示する責任」があると思います。しかしFが呼び出している全ての関数で発生する可能性のある例外の集合E1とFが上位に見せるべき例外の集合E2は一致することもあれば一致しないこともあると思うのです。
Fが呼び出す関数で発生する例外について「F自身が責任をもって発生しないようにする」とか「その例外が発生したことは上位の誤りであると考えそのまま上位へパス」するか「Fがその実装で用いている関数の詳細や例外の種類を上位へそのまま見せるのが不適切という判断に基づきF自身の機能に配慮したなにか別の例外に置き換えて上位へ報告するか」は選択の余地があろうかと思います。
・・・
自分のコメントに書いた内容は(自分でいうのも間抜けですが)自身の無い点があります。
- こうしたFの設計が常にできてしかるべき(実際に誰もがやっている、また自分ができている)か
- ライブラリーが充分分かりやすいドキュメントとともに配布されているか
例えば実引数の範囲が不適切だからIllegalArgumentExceptionが発せられるといったことが一々書かれていないがそれは常識として書かれていないが、それがどこかにきちんと書かれているかとか・・・
自分は大規模になればなるほどこうした例外の設計は困難を極めると想像します。しかし、例外設計に対する哲学と方法論をお持ちのプロの方ならそう難しいものではないのかも知れません。自分自身、こうした訓練や知見が不足している自覚があるためか例外設計が大変難しく感じます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/02 11:06