例外の必要性

Question

OOPでは例外は欠かせないもので、これをしっかり書きましょうとよく言われています。では、例外はどの例外をどこまで書けばよいのかという疑問を感じました。

http://qiita.com/mikakane/items/dafd3d28c27311e5f429に載っているような例外があるかと思いますが、こういうクラスのこういう処理の場合はこの例外を設定する必要がないというのを、理由をつけて教えてください。

追記：多数回答ありがとうございます、聞きたいことを具体的に書くと、BadFunctionCallException であるとか、OverflowException とかを業務で書いたことがないのですが、どんな場合書くべきで、どんな場合省力した方がコードのスリム化につながり書くべきではないかという点です。

また、設計の際に例外が想定できてなくて、デプロイ後、お客様側で画面が真っ白になるみたいの（Javaとかだと回避できる方法があるんでしょうか・・）を避けるためにできる工夫があれば教えていただきたいです。

Comments

[cateye]

皆さんの回答が私にはずれて感じるので確認です。
捕捉しないでよい例外が言語、ＯＳの仕様としての例外の事かどうかが曖昧です。
PHPの例外のみでしょうか？ それとも、下位モジュールが発生した例外も含みますか？　また、捕捉しなくてよいというのは、何を捕捉するかの裏返しなので捕捉しなくてはならない例外が分かればいいと思いますが？

[tixure55]

回答ありがとうございます、OSの仕様についての例外等は私には敷居が高いので、phpの例外について回答いただければと思います。下位モジュールというのはよく分かりません。

Answer 1

「例外 Advent Calendar 2014」の一連記事でよく整理されていると思います。（残念ながら途中でおわってしまいましたが...）1日目の「例外入門以前」からどうぞ。

OOPでは例外は欠かせないもので、これをしっかり書きましょうとよく言われています。

（Chironianさんと同意見ですが）「OOP」と「例外」の間に、特段の強い関係性は無いとおもいます。OOPでなくとも例外機構は存在しますし、例外機構のないOOP言語も存在します。

Answer 2

ケースバイケースなので、これはこの時といった回答はできません。

例外処理をすべき対象は下記の通りです。
・アプリケーション実行時の例外
→「ファイルが無い」や「ファイルにアクセスできない」、「データベースにアクセスできない」、「通信先のサーバから応答がない」などの外的要因の例外は例外処理すべきでしょう。

・仕様で決まっている例外
→仕様で「この場合は例外として処理する」等の取り決めがある場合は例外処理をする。

Comments

[tixure55]

RuntimeExceptionは継承関係が多数あるので、場合によって使い分けるようにしたいと思います。

Answer 3

例えば、DBから種類という意味合いの数字を引っ張ってくるクラスの場合、1,2,3がデータ範囲とすると、
これ以外は想定範囲外なので、1,2,3以外は例外をスローしたほうが良いです。

これが、UIの入力値であれば、データ範囲外で入力されるケースは容易に考えられると思うので、
入力チェックで弾くようにし、例外は書いてはダメです。

そのアプリケーションにとって、想定外であるかないかが、例外を書くか書かないかになると思います。

Comments

[tixure55]

回答ありがとうございました。バリデートで済むところはバリデートしろということですね。

Answer 4

追記：多数回答ありがとうございます、聞きたいことを具体的に書くと、BadFunctionCallException であるとか、OverflowException とかを業務で書いたことがないのですが、どんな場合書くべきで、どんな場合省力した方がコードのスリム化につながり書くべきではないかという点です。

上記のみに回答させていただきます。
まず、OverflowExceptionとか書いたことが無い、という事はきちんと条件分岐でエラーを捕らえられていると言う事で、良いことかと思います（きちんと動いていればですがね、、）。

会社や組織の方針でも違うかもしれませんが、私などは、基本は、
「例外」
とはいわゆる、
「想定外」
の範疇のみの処理方法だと考えています。

基本的には、まずは、
「例外が発生しない」
というのが最優先条件でプログラムは組まれるべきであると思っています。
if文などの、分岐構造で、基本的にできる限りの条件洗い出し、分岐を行う事が必要で、意図した流れのみにするべきです。

たとえばOverflowExceptionについては、その前段の計算部分にて、オーバーフローしないうように、逆にオーバーフローするようなら、パラメータが範囲外だよ、と呼び出し元にエラーとして戻すのが最優先です。それであれば、OverflowExceptionは必要ありません。

例外を使うのは
・本当に想定していない場合（そんな事がいつ起こるかな？と、やもやと想像して実装する）
・使っているライブラリなどが例外を出す仕様の場合（しょうがないから使う）
・どうやっても、その先に進めないような場合に使う
＝＞これは、例えば、

int arrayValue(int index){
 return a[index];
}

のような、関数の場合、indexに配列外の値が設定された場合には、メモリ不正アクセスで死亡という事態になってしまうため、この場合はしょうがないので例外を使います。

int arrayValue(int index){
 if(inxd >= MAX_ARRAY)throw(xxxx);
 return a[index];
}

程度に絞るべきだと思います。
基本は、if文です。

最後に・・・
・簡略化
・エラーが発生したあとの動作についてあまり重要性が無いような場合
において、たとえばすべてOverflowExceptionで受けて、エラーとして、戻す実装をする事もまれにありますが、パラメータ違いでの意図的な例外なのか、想定外のパラメータでの例外なのかわからなくなってしまうので、あまり本来の姿ではないと思っています。

例外とは、どちらかというと、ライブラリなどを提供する側が、使用者側の想定がすべて受け止められない場合があるため、（上記のarrayValue関数のような）に使用すべきものであるので、
そのような例外が、頻発することは、そもそもの使用方法の誤りかと思います。

よって、意図的に例外をキャッチする機会は、あまりあってはならないのが、本来の姿かと。

ご参考になれば。

Answer 5

OOPでは例外は欠かせないもので、これをしっかり書きましょうとよく言われています。

えっ？ そうなんですか！！
例外は便利な道具であり、そのメリットとデメリットをきちんと判断した上で使うものです。
つまり、例外を投げることを推奨するようなものではないと思います。
ただし、例外をキャッチする方はしっかりと書くべきです。ライブラリや言語システムも投げてきますので、プログラムを終了させたくない場合は捕まえるしかないです。

ちなみに、例外はエラーを返却する方法の１つです。もう１つの方法は戻り値や参照パラメータで返却することです。それぞれ一長一短があるのでどちらを使うのか良く検討するべきです。
原則は戻り値で返却し、特定のケースで例外を使うのが妥当と思います。

さて、私自身は、パッと思いつく限り、下記のようなケースで例外を投げます。
0. リリース後もassertionさせる時。
0. エラーの種類ごとに分けてエラー・リカバリさせたい時。
0. 複数の関数呼び出しに対して、纏めてエラー・リカバリさせたい時。
0. 多重に関数呼び出しされている奥のほうで発生したエラーを遠くの呼び出し元でエラー・リカバリさせたい時。
（後、C++では例外を投げる処理は重いので、頻繁に動作する正常系処理では例外を投げないようにしています。)

と書いてる私はC++erです。でも、バリバリOOPしてますのでOOP的な共通事項について回答させて頂きました。

【追記へのコメントです】

設計の際に例外が想定できてなくて、デプロイ後、お客様側で画面が真っ白になるみたいの
(Javaとかだと回避できる方法があるんでしょうか・・）を避けるためにできる工夫があれば
教えていただきたいです。

「想定していない例外(エラー)」が起きることを想定して(笑)、プログラムするってことですね。
できるだけ大元でtry-catchしておくとか？
でも、発生するエラーを予想していない以上ちゃんと回復することは無理ではないでしょうか？
最悪、大元のtry-catchが原因でプログラムが異常終了さえできなくなってハマったりもしますので、かなり難しいです。

ですので、理想は「想定していないエラー」があってはいけないのだと思います。
例外の場合、これが非常に難しいのですよね。奥深いところで発生する例外まで調べるのってなかなか。
だから、できるだけ理想に近づけるよう努力するしかないです。
なので、例外を使う明確なメリットが無い時まで例外を使うのはよろしくないと思います。

Comments

[tixure55]

回答ありがとうございます、C++で例外ときくと、メモリの割当に失敗した場合とかライブラリの機能の取得失敗といった例外のtry〜catchがありそうですね。複数の関数呼び出しに対してまとめてリカバリとは具体的にはどのような処理を書くのでしょうか？

[Chironian]

例外自体は、Javaにある例外の一部(たぶん大量に)はC++にもあるし、逆も真と思います。(メモリ割当失敗はOSが返却するものですのでJavaにもあります)

複数の関数呼び出しの件は例えば下記です。(C++っぽくでごめんなさい。)
----------------------------
void sample(int x)
{
　　try
　　{
　　　　foo(); // CustomExceptionを投げる可能性がある
　　　　bar(); // CustomExceptionを投げる可能性がある
　　　　foo(); // CustomExceptionを投げる可能性がある
　　}
　　catch(CustomException e)
　　{
　　　　エラー処理;
　　}
}
----------------------------
この代わりに下記のように書くこともできますが、なかなか面倒です。
　①同じエラー処理を複数回書くことになる
　②同じことを何度も書くのは悪手だから関数化しないといけない
　③関数化したらsample()内のxにアクセスするには再度渡す必要がある
　　１つなら大したことないけど、沢山あるとこれがまたたいへん
----------------------------
void sample(int x)
{
　　if (foo() == Error) {
　　　　エラー処理;
　　}
　　if (bar() == Error) {
　　　　エラー処理;
　　}
　　if (foo() == Error) {
　　　　エラー処理;
　　}
}
----------------------------