失敗したメソッドから返すものと投げるタイミング

Question

私は最近、方法から戻ってきたものについて考えていましたが、方法が失敗したときに私が返す4つのものがあることに気付きました。

私の悩みは、この点で私のコードがあまりにも合理的ではないことです。そのため、私はあなたの「ベストプラクティス」について質問したいと思っていました。

そうはFooをとり、バーのリストを返すメソッドを想像することができます：

public IList<Bar> Method(Foo something); 

以上の一般的なそれを維持するために：

public IBar Method(IFoo something); 

質問は、あなたがどのような種類の上に戻る何をすべきかです失敗のオプションは次のようになります。

1. 空の戻り型のように：新しいリスト;または：新しいEmptyBar（）;
2. ヌル
3. のような失敗を示す特殊なリスト値が例外
4. 投げる：私は本当にオプション4を憎む新しいリスト{新しいFailureBar（）}

ので - 私はほとんどときに聞いてinteresstedを他の3つのオプションと理由を使用してください。

Answer 1

私は、失敗の性質によって空リストと例外のどちらかを選択します。

など。

データベースが接続に失敗した場合 - 例外。

クエリで結果が返されなかった場合 - 空のリスト。

Answer 2

メソッドのロジックは、メソッドが返す方法によって異なる場合があります。したがって、空のリストを返す方法は問題ありません。

ビジネスロジックで空のリストを持たない場合は例外をスローします。それが間違ったために 'Foo something'が渡された場合、アサートまたはロジック例外が発生します。それは、データベース接続やファイルシステムエラーのような外部データの問題が原因で、ランタイム例外が発生した場合です。

この動作を後で理解することは非常に難しいでしょう。

Answer 3

ケース1：

方法は、それが例外をスローする必要が期待されていないん問題が、発生した場合。呼び出し元のコードは、例外

ケース2の世話をする必要があります。

値にnullを/空/リストを返すべきである他のすべてのケースメソッド

。呼び出し元の関数は、 nullと を空にして、を処理する必要があります。

Answer 4

「失敗」という言い方によって異なります。

予期せぬことが起こったという意味での失敗であれば、例外をスローします。おそらく、引数が間違っていた場合の引数の例外、ファイルから読み込めなかったときのIOExceptionなどです。

'失敗'は、指定されたパラメータ値で項目が見つからない場合、空のリストを返します。あなたがコレクションではないオブジェクトを返す場合は、nullを返します。

私はエラーのような-1のような特別な結果コードを返すことはありません。私は本当にそれが好きではありません。人々はコードについて忘れがちであり、時間の経過とともに変化し、これらの結果コードをチェックするif文がひどくmaintanableで終わることになります。

Answer 5

わからないこれらは普遍的に適用することができますが、私は以下のルールではなく快適だ場合：

1. メソッドの名前がDoFooであれば、それは何らかの理由ではFooを行うことができないなら、それは投げる必要があります：ネットワークリソースをFooはインタフェースのこの特定の実装でサポートされていません。オブジェクトは不整合な状態にあります。
2. メソッドの名前がGetBarの場合は、もう1つのオプション、nullを返します。しかし、TryGetBar、GetBarOrNullなどのように名前を付けて反映する方が良いでしょう。もちろん、null戻り値は特別なものを示し、すべての例外条件に応答する必要があります。

Answer 6

何かが、私が何をしようとしていると干渉する場合にのみ、私は通常、ほとんどの他の例ではnullを返しに行く

ような悪い入力パラメータ、データベース・エラーなどとして、例外をスローしていました、 nullをチェックするのは当然ですが、保持するはずのデータが空の場合は空のリストを返します。

Answer 7

例外が予想される場合は、例外をスローします。

私がBarを探していて、見つからなかった場合、nullを返します。

List<Bar>を探していても見つからなかった場合は、空のList<Bar>を返します。

nullを見つけることが非常に一般的になり、それを使用することが理にかなっている場合は、Null Object patternを実装してEmptyBarを返します。

だから、あなたの現在のアプローチに今私が同意すると言うのは公正だと思います。私はどんなプロジェクトでも一貫していることを確かめて、&と異なるケースで異なるアプローチを組み合わせないでください。

Answer 8

要素が見つからない場合は、空のリストを返します。これは、Null Objectパターンの特殊なケースです。すべてのケースを一貫して扱うことができます。これは、クライアントが値がnullかどうかを確認する必要がないことを意味します。悪いことに、チェックしないと、Null Pointer Exceptionがスローされ、何が原因であるかを知るためのうれしいデバッグが行われます。あなたに非常に正当な理由がある場合に限り、nullを返します。

更新：Martin Fowler氏がnullを返すことにより良い代替手段について説明します。http://martinfowler.com/eaaCatalog/specialCase.html

をしかし、それはに、データベース例外、ストリームの例外などはずだったとして、あなたの方法を動作しませんでした場合に例外をスロー

Answer 9

あり、ここでの答えは2つの質問ARW：

• は、空の結果との定期的な実行とは概念的に異なる機能の故障ですか？発呼者は、これらのケースのどれが起こったのかを現実的に知る必要がありますか？その場合、空のリストを返すことはオプションではありません。私は理論的には "特別な"空のリストを返すことができると思いますが、それは難読化です。
• 機能が失敗した場合、誰が通常反応する必要がありますか？すぐに呼び出されるコードではなく、それ以上のものであれば、Exceptionが最もクリーンなソリューションです。

Answer 10

私はできるだけそれをシンプルに保つために例外または空の戻りリストにそれを減らすだろう

1. 空の戻り値の型のように：新しいリスト。または：新しいEmptyBar（）;

リストを埋める操作が明白なエラーなしで正しく完了したが、結果が返されない場合は、これが返されます。これはIMOを意味するものです。これはまた、（例えば）リストをループするリターンに依存するコードが特別な処理を必要としないことを意味する。

<オール開始=「3」>
2. は例外

何かが機能して間違っている時に例外がスローされなければならないIMO

投げる - 例えばをファイルを開くことができない、接続できないなど計算がガベージを返しました - これは「返された結果がありません」とは異なります