関数失敗時に例外処理を投げるか戻り値で通知するかの指針について

お世話になっております。

例外処理についてですが、

関数失敗時に例外処理を投げるか、戻り値（例えばboolなど）で通知するか？
そもそもどういうときに例外を投げるべきか？

というのが、かなり深い内容でいろいろ調べてみたのですが、いろいろな主張があり、かなり混乱しています。

いろいろなサイトを拝見し、以下のように例外処理の指針を考えてみたのですが、この考え方が正しいのかどうか助言を受けたいです。
よろしくお願い致します。

前提

事前条件とは、以下のように理解しています。

メソッドを呼ぶ前に、呼び出し側が成立させる条件。つまり、引数が正しいことや、呼び出すタイミングが正しいことなど。

また、直接は関係ないかもしれませんが、ターゲットの言語はC#です。

例外として扱うもの

事前条件を満たさない場合、または事前条件を満たさないことによりメソッド内でエラーが起きた場合

（事前条件を満たすのは呼び出し側の責任であるという「契約による設計」の考え方）
→引数異常を起因としてメソッドが正常に動作できなくなった場合もここに該当する

事前条件を満たしているが、失敗責任の所在がメソッド内で閉じていない場合（失敗がネットワークなどに起因する場合）
事前条件を満たしているが、メソッド内で回復できないエラーが発生した場合

例外として扱わないもの

事前条件を満たしており、メソッド内で想定内の処理失敗（＝回復可能なエラー）した場合
事前条件を満たしており、メソッドの事後条件に処理失敗時のことが規定されている場合

→TryParseメソッドのように、「失敗したらfalseを返す」ということが予め表明されている場合

参考にしたサイト

行動規範の内容に同意します

回答2件

関数の呼び出し元でどのように処理したいかも関わってくるので、
やはり一概にどれがいいとは言いにくいです。

仮にその関数がfalseを返した時に処理を終了するような業務ロジックの場合、
条件分岐を作って、呼び出し元で再度任意の戻り値を設定しないといけないと思います。
逆に例外を投げれば、必要な場所でハンドリングできたり、FWなどで吸収できるので、
テストも含めコーディング量が少なくて済みます。
例えば、DBへのupdateでupdate件数が0件だった場合などは例外として扱うほうが扱いやすいです。

また事前条件という形で丸められると、
その事前条件を決めるのが大変だと思います。

投稿2017/09/07 06:02