Ist es in Ordnung, NullPointerException programmgesteuert auszulösen? [closed]

Wenn es eine Nachbedingung gibt, darf der Rückgabewert einer Methode nicht null sein, was kann man tun?

ich könnte

assert returnValue != null : "Not acceptable null value";

aber Behauptungen könnten ausgeschaltet werden!

Also ist es in Ordnung zu tun

if(returnValue==null)
      {
           throw new NullPointerException("return value is null at method AAA");
      }

?

Oder ist es besser, eine benutzerdefinierte Ausnahme (wie NullReturnValueException ) für eine solche Bedingung zu verwenden?

Ich würde dir empfehlen, niemals zu werfen NullPointerException von dir selbst.

Der Hauptgrund, dies nicht zu tun, ist, wie Thorbjørn Ravn Andersen in einem Kommentar unten sagt, dass Sie „echte, schlechte NPEs“ nicht mit absichtlich geworfenen NPEs mischen wollen.

Bis Sie sicher sind, dass Sie in der Lage sind, „gültige“ NPE zu erkennen, würde ich die Verwendung empfehlen IllegalArgumentException wenn Sie das Ihrem API-Benutzer mitteilen möchten null ist kein gültiger Argumentwert. Das Verhalten Ihrer Methode bei der Übergabe von ungültigen Nullparametern sollte dokumentiert werden.

Eine andere (imho modernere) Option ist die Verwendung @NotNull Anmerkung neben dem Argument. Hier ist ein Artikel über die Verwendung der Annotation @NotNull.

Wie ich bereits erwähnt habe, kann es auch Fälle geben, in denen das Werfen von NPE weder für Sie noch für Ihre Teamkollegen verwirrend ist: Die Ursache für NPE sollte klar und erkennbar sein.

Wenn Sie beispielsweise eine Bibliothek mit Vorbedingungsmodul verwenden, wie z Guavadann finde ich Verwendung checkNotNull()-ähnliche Methoden sind eine bevorzugte Methode, um mit illegal übergebenen Nullen umzugehen.

checkNotNull(arg, msg) wirft NPE, aber aus dem Stacktrace ist ziemlich klar, dass es von produziert wurde Preconditions.checkNotNull() und daher handelt es sich nicht um einen unbekannten Fehler, sondern um ein erwartetes Verhalten.

Ich sehe kein Problem darin, eine NPE so früh wie möglich zu werfen, bevor die JVM dies für Sie erledigt – insbesondere für Nullargumente. Es scheint einige Diskussionen darüber zu geben, aber es gibt viele Beispiele in den Java SE-Bibliotheken, die genau dies tun. Ich kann nicht verstehen, warum NPE in dem Aspekt heilig sein sollte, dass Sie es nicht selbst werfen können.

Allerdings schweife ich ab. Bei dieser Frage geht es um etwas anderes. Sie sprechen von einer Nachbedingung, die besagt, dass der Rückgabewert nicht null sein darf. Sicherlich würde null in diesem Fall bedeuten, dass Sie einen Fehler haben innerhalb der sehr Methode?

Wie würden Sie das überhaupt dokumentieren? “Diese Methode löst eine NullPointerException aus, wenn der Rückgabewert unerwartet null ist”? Ohne zu erklären, wie das passieren konnte? Nein, ich würde hier eine Behauptung verwenden. Ausnahmen sollten für Fehler verwendet werden, die möglicherweise passieren können – nicht um Dinge abzudecken, die passieren können, wenn innerhalb der Methode etwas nicht stimmt, denn das hilft niemandem.

Angesichts dessen NullPointerException ist die idiomatische Art, einen unerwarteten Nullwert in Java zu kommunizieren, ich würde empfehlen, dass Sie einen Standard werfen NullPointerException und kein Eigenbau. Denken Sie auch daran, dass das Prinzip der geringsten Überraschung nahelegen würde, dass Sie keinen eigenen Ausnahmetyp für einen Fall erfinden, in dem ein Systemausnahmetyp vorhanden ist.

Zusicherungen sind gut zum Debuggen, aber nicht gut, wenn Sie bestimmte Bedingungen behandeln müssen, sodass die Fehlerbedingung nicht wirklich gut behandelt werden kann.

Das Problem mit NullPointerException ist, dass es auftritt, wenn Sie vergessen zu prüfen, ob etwas null ist oder das falsche Argument zu geben, das null ist und nicht sollte.

Aus meiner Erfahrung lernen Java-Programmierer sehr schnell, dass diese Ausnahme durch den Fehler im Code verursacht wird, daher wird es extrem verwirrend sein, sie manuell auszulösen die meisten von ihnen. IllegalArgumentException ist eine bessere Idee, wenn Sie inakzeptable Argumente übergeben (z. B. null, wo etwas nicht null sein darf).

Es löst auch eine andere Heuristik aus. NPE = jemand hat hier einen Fehler im Code gemacht, IllegalArgumentException = das der Methode übergebene Objekt ist ungültig.

Auf der anderen Seite sagt das Javadoc:

Anwendungen sollten Instanzen dieser Klasse auslösen, um dies anzuzeigen
andere illegale Verwendungen der null Objekt.

NPE zu werfen wäre also legalaber es ist nicht die übliche Praxis, also würde ich empfehlen IllegalArgumentException.

Es gibt sicherlich kein universelles Gesetz gegen das Auslösen einer NullPointerException, aber es ist schwer zu beantworten, ob Sie dies in einem so abstrahierten Beispiel tatsächlich tun sollten. Was Sie nicht tun möchten, ist, die Leute in die Lage zu versetzen, zu versuchen, NullPointerException abzufangen. Code wie folgt (echtes Beispiel, ich schwöre):

catch (NullPointerException npe) {
  if (npe.getMessage().equals("Null return value from getProdByCode") {
    drawToUser("Unable to find a product for the product type code you entered");
  } 
}

Ist ein todsicherer Indikator dafür, dass Sie etwas falsch machen. Wenn also der Null-Rückgabewert ein Indikator für einen Systemstatus ist, den Sie tatsächlich kommunizieren können, verwenden Sie eine Ausnahme, die diesen Status kommuniziert. Es gibt nicht viele Fälle, die mir einfallen, in denen es sinnvoll ist, eine Referenz auf Null zu überprüfen, nur um einen Nullzeiger zu entfernen. Normalerweise hätte die nächste Codezeile sowieso den Nullzeiger (oder etwas Informativeres) weggeschmissen!

http://pmd.sourceforge.net/pmd-5.0.1/rules/java/strictexception.html

“Vermeiden Sie das Auslösen von NullPointerExceptions. Diese sind verwirrend, da die meisten Leute davon ausgehen, dass die virtuelle Maschine sie ausgelöst hat. Erwägen Sie stattdessen die Verwendung einer IllegalArgumentException; dies wird eindeutig als eine vom Programmierer initiierte Ausnahme angesehen.”

Ich würde diese Verwendung von NullPointerException für ok halten, wenn Sie erinnern sich an die Beschreibung. Damit hat die untersuchende Person zu tun (Zeilennummern können sich verschieben). Denken Sie auch daran, zu dokumentieren, dass Ihre Methoden in besonderen Fällen Nullzeigerausnahmen auslösen.

Wenn Sie Ihre Methodenparameter gleich zu Beginn überprüfen, a throw new IllegalArgumentException("foo==null") ist für mich auch akzeptabel.