自然に発生させるのではなく、明示的にNullPointerExceptionをスローするのはなぜですか？

JDKソースコードを読むとき、作成者がパラメーターがnullかどうかを確認し、新しいNullPointerException（）を手動でスローすることがよくあります。なぜ彼らはそれをするのですか？メソッドを呼び出すと新しいNullPointerException（）がスローされるので、そうする必要はないと思います。（たとえば、HashMapのソースコードは次のとおりです:)

public V computeIfPresent(K key,
                          BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
    if (remappingFunction == null)
        throw new NullPointerException();
    Node<K,V> e; V oldValue;
    int hash = hash(key);
    if ((e = getNode(hash, key)) != null &&
        (oldValue = e.value) != null) {
        V v = remappingFunction.apply(key, oldValue);
        if (v != null) {
            e.value = v;
            afterNodeAccess(e);
            return v;
        }
        else
            removeNode(hash, key, null, false, true);
    }
    return null;
}

頭に浮かぶ理由はいくつかあり、いくつかは密接に関連しています。

フェイルファスト：失敗する場合は、後で失敗するよりも早く失敗することが最善です。これにより、問題を発生源の近くで捉えることができ、問題の特定と回復が容易になります。また、失敗するはずのコードでCPUサイクルを浪費することも回避します。

意図：例外をスローすることで、エラーが意図的に存在し、作成者が結果を認識していることが保守担当者に明確に示されます。

一貫性：エラーが自然に発生することが許可されている場合、すべてのシナリオで発生するわけではありません。たとえば、マッピングが見つからない場合はremappingFunction使用されず、例外はスローされません。入力を事前に検証することで、動作がより確定的になり、ドキュメントがより明確になります。

安定性：コードは時間とともに進化します。例外が発生したコードは、少しのリファクタリングの後、自然にそうするのをやめるか、さまざまな状況下でそうするかもしれません。明示的にスローすることで、動作が誤って変更される可能性が低くなります。

これは、明確性、一貫性、および余分な不要な作業が実行されないようにするためです。

メソッドの先頭にガード句がない場合はどうなるか考えてみてください。それは、常に呼ぶだろうhash(key)とgetNode(hash, key)するときにもnullために渡されていたremappingFunctionNPEがスローされる前に。

さらに悪いことに、if条件がfalse次にある場合、else分岐を使用します。分岐はまったく使用されませんremappingFunction。つまり、a nullが渡されたときにメソッドが常にNPEをスローするとは限りません。かどうかは、マップの状態によって異なります。

どちらのシナリオも悪いです。if nullがremappingFunctionメソッドの有効な値でない場合は、呼び出し時のオブジェクトの内部状態に関係なく、常に例外をスローする必要があり、スローしようとしているという意味で無意味な不要な処理を行わずに例外をスローする必要があります。最後に、ソースコードをレビューする人が誰でもそれができることをすぐにわかるように、ガードをすぐ前に置くことは、クリーンで明確なコードの良い原則です。

例外がコードのすべてのブランチによって現在スローされている場合でも、コードの将来のリビジョンでそれが変更される可能性があります。最初にチェックを実行すると、確実に実行されます。

@shmoselの優れた答えによってリストされた理由に加えて...

パフォーマンス：（一部のJVMでは）JVMに実行させるのではなく、NPEを明示的にスローすることでパフォーマンスが向上する可能性があります。

これは、JavaインタープリターとJITコンパイラーがNULLポインターの逆参照を検出するために取る戦略に依存します。1つの戦略は、nullをテストせず、代わりに、命令がアドレス0にアクセスしようとしたときに発生するSIGSEGVをトラップすることです。これは、参照が常に有効である場合の最速のアプローチですが、NPEの場合はコストがかかります。

nullコード内での明示的なテストにより、NPEが頻繁に発生するシナリオでSIGSEGVのパフォーマンスヒットが回避されます。

（これは現代のJVMで価値のあるマイクロ最適化になるとは思えませんが、過去にあったかもしれません。）

互換性：例外にメッセージがない理由として考えられるのは、JVM自体によってスローされるNPEとの互換性です。準拠したJava実装では、JVMによってスローされたNPEにnullメッセージがあります。（Android Javaは異なります。）

他の人々が指摘したこととは別に、ここでは慣習の役割に​​注目する価値があります。たとえばC＃では、このような場合に例外を明示的に発生させるという同じ規則がありますがArgumentNullException、これは具体的にはであり、やや具体的です。（C＃の慣例は、NullReferenceException 常にある種のバグを表すというものです。非常に簡単に言うと、製品コードで発生することは決してありません。当然のことですが、ArgumentNullException通常は発生しますが、「you not notライブラリを正しく使用する方法を理解してください」という種類のバグ）。

つまり、基本的には、C＃NullReferenceExceptionはプログラムが実際に使用しようとしたArgumentNullExceptionことを意味しますが、値が間違っていることを認識し、それを使用しようとすることさえありませんでした。ArgumentNullException問題のメソッドにはまだ副作用がない（メソッドの前提条件に失敗したため）ため、影響は実際には（状況によって）異なる場合があります。

ちなみに、ArgumentNullExceptionまたはのようなものを発生させている場合IllegalArgumentException、それはチェックを行うポイントの一部です。「通常」取得するのとは異なる例外が必要です。

どちらの方法でも、明示的に例外を発生させることで、メソッドの前提条件と予期される引数を明示的にすることで、コードの読み取り、使用、保守が容易になります。を明示的にチェックnullしなかった場合、誰もnull引数を渡さないと考えていたのか、それとも例外をスローするためにそれをカウントしていたのか、それともチェックするのを忘れたのかはわかりません。

これは、後でマップを使用しているときにエラーが発生した理由が理解できなくなるのではなく、エラーが発生するとすぐに例外が発生するためです。

一見不安定なエラー状態が明確なコントラクト違反に変わります。関数には、正常に動作するためのいくつかの前提条件があるため、事前にチェックして、それらが満たされるようにします。

その結果computeIfPresent()、例外が発生したときにデバッグする必要がなくなります。例外が前提条件チェックによるものであることがわかると、不正な引数を指定して関数を呼び出したことがわかります。チェックがなかった場合はcomputeIfPresent()、例外がスローされる原因となるバグが含まれている可能性を除外する必要があります。

ジェネリックをスローするNullPointerExceptionことは、それ自体が契約違反を示すものではないため、明らかに悪い選択です。IllegalArgumentExceptionより良い選択でしょう。

サイドノート：
Javaがこれを許可するかどうかはわかりませんが（私は疑問です）、C / C ++プログラマーassert()はこの場合にを使用します。これは、デバッグに非常に優れています。提供された場合、プログラムをすぐにクラッシュし、可能な限りハードクラッシュするように指示します。条件はfalseと評価されます。だから、あなたが走った場合

void MyClass_foo(MyClass* me, int (*someFunction)(int)) {
    assert(me);
    assert(someFunction);

    ...
}

デバッガーの下で何かがNULLいずれかの引数に渡された場合、プログラムは行で停止し、どの引数がNULLであるかを示します。自由に呼び出しスタック全体のすべてのローカル変数を調べることができます。

自然に起こらない可能性があるからです。次のようなコードを見てみましょう。

bool isUserAMoron(User user) {
    Connection c = UnstableDatabase.getConnection();
    if (user.name == "Moron") { 
      // In this case we don't need to connect to DB
      return true;
    } else {
      return c.makeMoronishCheck(user.id);
    }
}

（もちろん、このサンプルにはコードの品質に関する多くの問題があります。完璧なサンプルを想像するのが面倒です）

c実際には使用されNullPointerExceptionず、c == null可能な場合でもスローされない状況。

より複雑な状況では、そのようなケースを突き止めることは非常に簡単ではなくなります。これは、一般的なチェックのようif (c == null) throw new NullPointerException()に優れている理由です。

それ以上の損傷を保護すること、または不整合な状態になることは意図的です。

ここで他のすべての優れた回答とは別に、いくつかのケースも追加したいと思います。

独自の例外を作成する場合は、メッセージを追加できます

あなた自身を投げるなら、あなたNullPointerExceptionはメッセージを加えることができます（あなたは間違いなくそうするべきです！）

デフォルトのメッセージは、たとえばnullfrom new NullPointerException()とそれを使用するすべてのメソッドですObjects.requireNonNull。そのnullを出力すると、空の文字列に変換されることさえあります...

少し短くて情報がない...

スタックトレースは多くの情報を提供しますが、ユーザーが何がnullであるかを知るには、コードを掘り起こして正確な行を確認する必要があります。

ここで、NPEがラップされ、ネット経由で送信されたと想定します。たとえば、おそらく異なる部門間または組織間で、Webサービスエラーのメッセージとして送信されます。最悪のシナリオ、誰が何をnull表すのか理解できないかもしれません...

連鎖メソッド呼び出しはあなたが推測し続けるでしょう

例外は、例外が発生した行についてのみ通知します。次の行について考えてみます。

repository.getService(someObject.someMethod());

あなたは、NPEを取得し、それは次のいずれか、この行を指している場合repositoryやsomeObjectヌルでしたか？

代わりに、これらの変数を取得したときにそれらをチェックすると、少なくともそれらが処理されている唯一の変数である行をポイントします。そして、前述のように、エラーメッセージに変数の名前または類似の名前が含まれている場合はさらに良いでしょう。

大量の入力を処理する際のエラーは、識別情報を提供するはずです

プログラムが数千行の入力ファイルを処理していて、突然NullPointerExceptionが発生したとします。場所を見て、一部の入力が正しくないことに気付きました...どの入力ですか？そのファイルのどの行を修正する必要があるかを理解するには、行番号、おそらく列または行テキスト全体についての詳細情報が必要になります。