Manchmal sehe ich Entwickler, die Bibliotheken wie Guavas Vorbedingungen verwenden, um die Parameter für Nullen am Anfang einer Methode zu validieren. Wie unterscheidet sich dies davon, NPE während Laufzeit zu erhalten, da eine Laufzeitausnahme auf beide Arten auftritt?Wie werden Nullen durch Bibliotheken besser geprüft als NPE?
EDIT: Wenn es gute Gründe gibt, sollten Entwickler nicht Bibliotheken für Null-Überprüfung auf allen Methoden verwenden?
Einige Gründe dafür sind:
Letztlich ist es eine Frage des Geschmacks IMO. Ich habe Programme gesehen, die inhärent null sicher sind und keine Vorbedingungen erfordern.
Niemand sollte den Wert von benutzerdefinierten Fehlermeldungen unterschätzen. – biziclop
Eine Folgefrage basierend auf den Antworten hinzugefügt. Wiederholen Sie die Frage hier: Wenn es gute Gründe gibt, sollten Entwickler dann nicht Bibliotheken verwenden, um alle Methoden auf Null zu prüfen? – Glide
Im Allgemeinen erfordern nur Methoden, die "extern" verwendet werden, Argumentüberprüfungen. Sobald Sie sich in Code befinden, den Sie kontrollieren, insbesondere private Methoden, können Sie sich oft beweisen, dass die Argumente nicht null sein müssen (und natürlich auf andere relevante Weise korrekt sind). Meine allgemeine Regel ist, dass jede öffentliche Methode oder jeder Konstruktor immer Argumente überprüft. – isomeme
Es gibt verschiedene Gründe. Ein großer, wie in den Kommentaren erwähnt, ist es, die Überprüfung im Voraus zu erledigen, bevor irgendwelche Arbeiten erledigt werden. Es ist auch nicht ungewöhnlich, dass eine Methode über einen Codepfad verfügt, in dem ein bestimmter Parameter niemals dereferenziert wird. In diesem Fall können ungültige Aufrufe der Methode manchmal keine Ausnahme erzeugen, wenn sie nicht vorab überprüft werden. Das Ziel ist es sicherzustellen, dass sie immer eine Ausnahme erzeugen, so dass der Fehler sofort gefangen wird. Das heißt, ich brauche nicht notwendigerweise checkNotNull, wenn ich sofort den Parameter in der nächsten Zeile oder etwas dereferenzieren werde.
Es gibt auch den Fall von Konstruktoren, wo Sie checkNotNull vor dem Zuweisen eines Parameters zu einem Feld möchten, aber ich denke nicht, dass Sie darüber reden, da Sie über Methoden sprechen, wo der Parameter verwendet wird sowieso.
Eines meiner Lieblings-Software-Prinzipien ist "Fail early, fail loud". Wenn Sie ein schlechtes Argument so schnell wie möglich erfassen und melden, wird die Diagnose und das Debugging erheblich vereinfacht. – isomeme
Es könnte sein, wenn Sie nach vorne schauen, dass Sie noch keine Arbeit erledigt haben, Arbeit, die Sie zurückrollen oder in einem inkonsistenten Zustand verlassen müssen, wenn eine NPE mitten in diese Arbeit geworfen wurde? –
Sie können auch eine Ausnahme mit mindestens einer sinnvollen Nachricht an den Benutzer auslösen (mindestens viel besser als eine NullPointerException) –
Null-Parameter führt nicht immer zu unmittelbarer NPE. Zum Beispiel kann es einem Feld oder einer Sammlung hinzugefügt werden und zu Fehlern führen, die schwer zu untersuchen sind. –