取得メソッドは、戻り値を生成できないときに「null」を返すか、例外をスローする必要がありますか？[閉まっている]

見つかった場合にオブジェクトを返すことになっているメソッドがあります。

それが見つからない場合、私は以下を行う必要があります：

1. nullを返す
2. 例外を投げる
3. その他の

常に値を見つけることを期待している場合、値がない場合は例外をスローします。例外は問題があったことを意味します。

値が欠落しているか存在する可能性があり、両方がアプリケーションロジックに対して有効な場合は、nullを返します。

より重要：コードの他の場所で何をしますか？一貫性は重要です。

本当にエラーである場合にのみ、例外をスローします。オブジェクトが存在しないことが予想される場合は、nullを返します。

そうでなければ、それは好みの問題です。

原則として、メソッドが常にオブジェクトを返す必要がある場合は、例外を使用してください。時々発生するnullを予期していて、それを特定の方法で処理したい場合は、nullを使用してください。

あなたが何をするにせよ、私は3番目のオプション、「WTF」を示す文字列を返すことを強くお勧めします。

nullがエラーを示さない場合は、nullを返します。

nullが常にエラーの場合は、例外をスローします。

nullが例外になる場合は、2つのルーチンをコーディングします。1つのルーチンは例外をスローし、もう1つはオブジェクトを出力パラメーターで返すブールテストルーチンで、オブジェクトが見つからなかった場合はfalseを返します。

Tryルーチンを誤用するのは難しいことです。nullをチェックするのを忘れるのは本当に簡単です。

したがって、nullがエラーの場合は、次のように記述します

object o = FindObject();

nullがエラーでない場合は、次のようなコードを記述できます。

if (TryFindObject(out object o)
  // Do something with o
else
  // o was not found

前述のオプションを要約して、いくつかの新しいオプションを投入したいと思います。

1. nullを返す
2. 例外を投げる
3. nullオブジェクトパターンを使用する
4. メソッドにブール型パラメーターを提供し、呼び出し元が例外をスローすることを希望するかどうかを選択できるようにする
5. 追加のパラメーターを提供して、呼び出し元が値を設定できない場合に値が見つからない場合に戻す

または、これらのオプションを組み合わせることができます。

ゲッターのオーバーロードされたバージョンをいくつか提供して、呼び出し元がどちらの方法に進むかを決定できるようにします。ほとんどの場合、最初のものだけが検索アルゴリズムの実装を持ち、他のものは最初のものをラップするだけです：

Object findObjectOrNull(String key);
Object findObjectOrThrow(String key) throws SomeException;
Object findObjectOrCreate(String key, SomeClass dataNeededToCreateNewObject);
Object findObjectOrDefault(String key, Object defaultReturnValue);

実装を1つだけ提供することを選択した場合でも、契約を明確にするためにそのような命名規則を使用することをお勧めします。これは、他の実装も追加することを決定した場合に役立ちます。

あなたはそれを使いすぎてはいけませんが、多くの異なるエラー処理規則を持つ何百もの異なるアプリケーションで使用するヘルパークラスを書くとき、それは役立つかもしれません。

nullオブジェクトパターンを使用するか、例外をスローします。

使用しているAPIと一致している。

例外をスローする利点：

1. 呼び出しコードの制御フローをよりクリーンにします。 nullをチェックすると、try / catchによってネイティブに処理される条件付きブランチが挿入されます。nullのチェックは、何をチェックしているのかを示していません-予期しているエラーを探しているのでnullをチェックしていますか、それともダウンチェーンでそれを渡さないようにnullをチェックしていますか？ ？
2. 「null」の意味のあいまいさを取り除きます。 nullはエラーを表しているのですか、それとも実際に値に格納されているのはnullですか？その決断の根拠となるものが1つしかない場合は、言うのは難しいです。
3. アプリケーションのメソッド動作間の一貫性が向上しました。 例外は通常、メソッドシグネチャで公開されるため、アプリケーションのメソッドがどのエッジケースに対応するか、およびアプリケーションが予測可能な方法でどのような情報に対応できるかをより理解することができます。

例を使用した詳しい説明については、http：//metatations.com/2011/11/17/returning-null-vs-throwing-an-exception/を参照してください。

あなたの言語とコードが促進するかどうかに依存します：LBYL（あなたが跳躍する前に見てください）またはEAFP（許可よりも許しを求める方が簡単です）

LBYLは、値をチェックする必要がある（したがって、nullを返す）
と言っています

上記に同意しますが、例外は例外/エラー条件に使用する必要があり、チェックを使用する場合はnullを返すのが最適です。

EAFPとLBYLのPython：
http ://mail.python.org/pipermail/python-list/2003-May/205182.html （Web Archive）

「オブジェクトが見つからないのは例外的なケースですか？」プログラムの通常の過程で発生することが予想される場合は、例外を発生させないでください（例外的な動作ではないため）。

ショートバージョン：例外を使用して例外的な動作を処理します。プログラムの通常の制御フローを処理するのではありません。

-アラン。

例外は、契約による設計に関連しています。

オブジェクトのインターフェースは実際には2つのオブジェクト間のコントラクトであり、呼び出し元はコントラクトを満たす必要があります。そうでない場合、レシーバーは例外で失敗するだけです。2つの可能な契約があります。

1）メソッドのすべての入力が有効です。この場合、オブジェクトが見つからない場合はnullを返す必要があります。

2）一部の入力のみが有効です。つまり、見つかったオブジェクトになります。その場合、呼び出し元が入力が正しいかどうかを判断できるようにする2番目のメソッドを提供する必要があります。例えば

is_present(key)
find(key) throws Exception

2番目のコントラクトの両方のメソッドを提供する場合に限り、例外がスローされても何も見つかりません。

私は単にnullを返し、それを適切に処理するために呼び出し元に依存することを好みます。（より良い言葉がないため）例外は、私が完全に「確実」である場合、このメソッドはオブジェクトを返します。その場合、失敗は例外的であり、スローする必要があります。

オブジェクトが見つからないことの意味によって異なります。

通常の状態の場合は、nullを返します。これはたまに発生する可能性があることであり、発信者はそれを確認する必要があります。

それがエラーの場合は、例外をスローします。呼び出し側は、オブジェクトが見つからないというエラー状態をどうするかを決定する必要があります。

最終的にどちらでも機能しますが、ほとんどの人は、例外が発生した場合にのみ例外を使用することをお勧めします。

ここにいくつかの提案があります。

コレクションを返す場合は、nullを返さずに、空のコレクションを返します。これにより、最初にnullチェックを行わなくても列挙を簡単に処理できます。

いくつかの.NET APIは、thrownOnErrorパラメータのパターンを使用して、オブジェクトが見つからない場合に、それが本当に例外的な状況かどうかを呼び出し元に選択させます。Type.GetTypeはこの例です。BCLのもう1つの一般的なパターンは、ブール値が返され、値が出力パラメーターを介して渡されるTryGetパターンです。

状況によっては、デフォルトまたは動作のないバージョンのいずれかであるNull Objectパターンを検討することもできます。重要なのは、コードベース全体でnullチェックを回避することです。詳細については、こちらをご覧くださいhttp://geekswithblogs.net/dsellers/archive/2006/09/08/90656.aspx

一部の関数では、パラメーターを追加します。

..., bool verify = true)

Trueはスローを意味し、Falseはエラーの戻り値を返すことを意味します。このように、この関数を使用する人は誰でも両方のオプションを利用できます。エラー処理を忘れる人のために、デフォルトはtrueである必要があります。

例外をスローする代わりにnullを返し、nullの戻り値の可能性をAPIドキュメントで明確に説明します。呼び出し側のコードがAPIを尊重せず、nullケースをチェックしない場合、おそらくいずれにせよ、何らかの "nullポインタ例外"が発生します:)

C ++では、オブジェクトを検索するメソッドを設定する3つの異なる方法を考えることができます。

オプションA

Object *findObject(Key &key);

オブジェクトが見つからない場合はnullを返します。素敵でシンプル。これで行こう。以下の代替アプローチは、out-paramsを嫌わない人のためのものです。

オプションB

void findObject(Key &key, Object &found);

オブジェクトを受け取る変数への参照を渡します。オブジェクトが見つからない場合、メソッドは例外をスローしました。この規則は、オブジェクトが見つからないことが本当に予期されていない場合に適しています。したがって、予期しないケースであることを示すために例外をスローします。

オプションC

bool findObject(Key &key, Object &found);

オブジェクトが見つからない場合、メソッドはfalseを返します。オプションAに対するこれの利点は、1つの明確なステップでエラーケースをチェックできることです。

if (!findObject(myKey, myObj)) { ...

nullが例外的な動作と見なされない場合にのみ言及する私は間違いなくtryメソッドを使用しています。

だから基本的に：

bool TryFindObject(RequestParam request, out ResponseParam response)

これは、ユーザーのコードも明確になることを意味します

...
if(TryFindObject(request, out response)
{
  handleSuccess(response)
}
else
{
  handleFailure()
}
...

クライアントコードが見つかったものと見つからなかったものの違いを知ることが重要であり、これが通常の動作であると考えられる場合は、nullを返すのが最善です。その後、クライアントコードは何をすべきかを決定できます。

通常はnullを返します。メソッドを呼び出すコードは、例外をスローするか、何か他のことを試みるかを決定する必要があります。

またはオプションを返す

オプションは基本的に、クライアントにブースケースの処理を強制するコンテナークラスです。Scalaにはこの概念があります。APIを調べてください。

次に、このオブジェクトに対してT getOrElse（T valueIfNull）のようなメソッドがあり、見つかったオブジェクトを返すか、クライアントが指定する代替案を返します。

nullを返す方が望ましい-

呼び出し側がチェックせずにそれを使用する場合、例外はとにかくそこで発生します。

発信者が実際に使用していない場合は、try/ catchブロックを課さないでください。

残念ながら、JDKは一貫性がなく、リソースバンドルの既存のキーにアクセスしようとすると、例外が見つかりません。マップから値を要求したときに、存在しない場合はnullを取得します。だから、私は勝者の答えを次のように変更します。見つかった値がnullの可能性がある場合は、見つからない場合は例外を発生させ、そうでない場合はnullを返します。したがって、1つの例外を使用してルールに従ってください。値が見つからない理由を知る必要がある場合は、常に例外を発生させてください。

参照を返すことになっている限りオブジェクト、NULLを返すのが良いでしょう。

ただし、C ++でのように、完全な血のようなものを返す場合（「return＆blah;」ではなく「return blah;」（または「blah」はポインタ））、NULLを返すことはできません。 「オブジェクト」タイプではありません。その場合、例外をスローするか、成功フラグが設定されていない空のオブジェクトを返すことが、私が問題に取り組む方法です。

誰かが例外処理のオーバーヘッドについて言及したとは思わないでください-例外をロードして処理するために追加のリソースを必要とするため、本当のアプリの強制終了またはプロセス停止イベントでない限り（先に進むと、害が大きくなります）を返すことを選びます呼び出し環境が適切であると解釈できることを評価します。

私はここでコンセンサスのように見えることに同意します（「見つかりません」が通常の可能な結果である場合はnullを返します。または、状況のセマンティクスが常にオブジェクトを見つける必要がある場合は例外をスローします）。

ただし、特定の状況によっては意味のある3番目の可能性があります。あなたのメソッドは、「見つからない」状態である種のデフォルトオブジェクトを返すことができます。これにより、呼び出しコードは、nullチェックや例外キャッチを必要とせずに常に有効なオブジェクトを受け取ることが保証されます。

nullを返しますが、例外は正確に次のとおりです。コードが予期しない動作をする場合。

例外はあるべき例外。null を返すことが有効な場合は null を返します。

メソッドがコレクションを返す場合、空のコレクションを返します（上記のように）。ただし、Collections.EMPTY_LISTなどは使用しないでください。（Javaの場合）

メソッドが単一のオブジェクトを取得する場合、いくつかのオプションがあります。

1. メソッドが常に結果を検出する必要があり、オブジェクトを検出しないことが実際の例外ケースである場合は、例外をスローする必要があります（Javaでは、チェックされていない例外を実行してください）
2. （Javaのみ）メソッドがチェック済み例外をスローすることを許容できる場合は、プロジェクト固有のObjectNotFoundExceptionなどをスローします。この場合、例外を処理するのを忘れた場合、コンパイラーから警告が出されます。（これは、Javaで見つからないものの私の好ましい処理です。）
3. オブジェクトが見つからず、メソッド名がfindBookForAuthorOrReturnNull（..）のような場合は、本当に大丈夫だとすると、nullを返すことができます。この場合、ある種の静的チェックまたはコンパイラチェックを使用することを強くお勧めします。これにより、nullチェックなしで結果の逆参照を防ぐことができます。Javaの場合、それは例えばすることができます。FindBugs（http://findbugs.sourceforge.net/manual/annotations.htmlの DefaultAnnotationを参照）またはIntelliJ-Checking。

nullを返す場合は注意してください。あなたがプロジェクトの唯一のプログラマーではない場合、実行時にNullPointerExceptions（Javaまたは他の言語では何でも）が発生します。したがって、コンパイル時にチェックされないnullを返さないでください。

ライブラリまたは例外をスローする別のクラスを使用している場合は、それを再スローする必要があります。ここに例があります。Example2.javaはライブラリのようなもので、Example.javaはそのオブジェクトを使用します。Main.javaは、この例外を処理する例です。呼び出し側のユーザーに意味のあるメッセージと（必要な場合は）スタックトレースを表示する必要があります。

Main.java

public class Main {
public static void main(String[] args) {
    Example example = new Example();

    try {
        Example2 obj = example.doExample();

        if(obj == null){
            System.out.println("Hey object is null!");
        }
    } catch (Exception e) {
        System.out.println("Congratulations, you caught the exception!");
        System.out.println("Here is stack trace:");
        e.printStackTrace();
    }
}
}

Example.java

/**
 * Example.java
 * @author Seval
 * @date 10/22/2014
 */
public class Example {
    /**
     * Returns Example2 object
     * If there is no Example2 object, throws exception
     * 
     * @return obj Example2
     * @throws Exception
     */
    public Example2 doExample() throws Exception {
        try {
            // Get the object
            Example2 obj = new Example2();

            return obj;

        } catch (Exception e) {
            // Log the exception and rethrow
            // Log.logException(e);
            throw e;
        }

    }
}

Example2.java

 /**
 * Example2.java
 * @author Seval
 *
 */
public class Example2 {
    /**
     * Constructor of Example2
     * @throws Exception
     */
    public Example2() throws Exception{
        throw new Exception("Please set the \"obj\"");
    }

}

それは本当にオブジェクトを見つけるかどうかに依存します。あなたが例外を何かを示すために使用すべきであるという考えの流派に従うなら、まあ、エラー、例外が発生しました：

• オブジェクトが見つかりました。オブジェクトを返す
• オブジェクトが見つかりません。例外を投げる

それ以外の場合は、nullを返します。