Wie vermeide ich die Suche nach Nullen in Java?

Lesezeit: 10 Minuten

ich benutze x != null vermeiden NullPointerException. Gibt es eine Alternative?

if (x != null) {
    // ...
}

  • @Shervin Das Ermutigen von Nullen macht den Code weniger verständlich und weniger zuverlässig.

    – Tom Hawtin – Wendeleine

    2. August 2010 um 9:17 Uhr

  • Null nicht zu verwenden ist den meisten anderen Vorschlägen hier überlegen. Ausnahmen auslösen, keine Nullen zurückgeben oder zulassen. Übrigens – das Schlüsselwort „assert“ ist nutzlos, da es standardmäßig deaktiviert ist. Verwenden Sie einen immer aktivierten Fehlermechanismus

    – ianpojman

    8. Juni 2012 um 19:40 Uhr

  • Nullen sollten im High-Level-Code vermieden werden. Tony Hoare, der Nullreferenzen erfunden hat, nennt sie „einen Milliarden-Dollar-Fehler“. Schau mal Hier für ein paar Ideen.

    – Andrii Polunin

    4. April 2016 um 13:05 Uhr

  • Scheint in Java 8 zu sein: static Objects.isNull(Object o) docs.oracle.com/javase/8/docs/api/java/util/Objects.html

    – Robert R. Evans

    23. Juni 2016 um 17:02 Uhr

  • Der häufigste Missbrauch von Null besteht darin, dass Leute Null anstelle einer leeren Sammlung zurückgeben. Das macht mich jedes Mal verrückt. Hören Sie auf, Nullen zu verwenden, und Sie werden in einer besseren Welt leben. Verbreiten Sie außerdem Ihren Code mit final Schlüsselwort und Sie werden in einer noch besseren Welt leben.

    – Jack

    29. Juni 2021 um 9:22 Uhr

Wenn Sie eine Java-IDE wie verwenden (oder dies planen). JetBrains IntelliJ-IDEE, Finsternis oder Netbeans oder ein Tool wie findbugs, dann können Sie Anmerkungen verwenden, um dieses Problem zu lösen.

Im Grunde genommen haben Sie es @Nullable Und @NotNull.

Sie können Methoden und Parameter wie folgt verwenden:

@NotNull public static String helloWorld() {
    return "Hello World";
}

oder

@Nullable public static String helloWorld() {
    return "Hello World";
}

Das zweite Beispiel lässt sich nicht kompilieren (in IntelliJ IDEA).

Wenn Sie das erste verwenden helloWorld() Funktion in einem anderen Codeteil:

public static void main(String[] args)
{
    String result = helloWorld();
    if(result != null) {
        System.out.println(result);
    }
}

Jetzt teilt Ihnen der IntelliJ IDEA-Compiler mit, dass die Prüfung nutzlos ist, da die helloWorld() Funktion wird nicht zurückgegeben nullimmer.

Parameter verwenden

void someMethod(@NotNull someParameter) { }

wenn du so etwas schreibst wie:

someMethod(null);

Dies lässt sich nicht kompilieren.

Letztes Beispiel mit @Nullable

@Nullable iWantToDestroyEverything() { return null; }

Dies tun

iWantToDestroyEverything().something();

Und Sie können sicher sein, dass das nicht passieren wird. 🙂 🙂

Dies ist eine nette Möglichkeit, den Compiler etwas mehr prüfen zu lassen, als er es normalerweise tut, und Ihre Verträge stärker zu machen. Leider wird es nicht von allen Compilern unterstützt.

In IntelliJ IDEA 10.5 und höher wurde Unterstützung für alle anderen hinzugefügt @Nullable @NotNull Implementierungen.

Siehe Blogbeitrag Flexiblere und konfigurierbarere @Nullable/@NotNull-Annotationen.

  • @NotNull, @Nullable und andere Nullheitsanmerkungen sind Teil von JSR 305. Sie können sie auch verwenden, um potenzielle Probleme mit Tools wie zu erkennen FindBugs.

    – Jacek S

    8. Mai 2010 um 16:33

  • Ich finde es seltsam nervig, dass das @NotNull & @Nullable Schnittstellen live im Paket com.sun.istack.internal. (Ich glaube, ich verbinde com.sun mit Warnungen vor der Verwendung einer proprietären API.)

    – Jonik

    30. Juni 2011 um 23:33

  • Die Code-Portabilität geht mit Jetbrains auf Null. Ich würde es mir zweimal überlegen, bevor ich mich auf die IDE-Ebene beziehe. Wie Jacek S sagte, sind sie auf jeden Fall Teil von JSR, was ich übrigens für JSR303 hielt.

    – Java Ka Baby

    8. September 2011 um 9:39 Uhr

  • Ich glaube wirklich nicht, dass die Verwendung eines benutzerdefinierten Compilers eine praktikable Lösung für dieses Problem darstellt.

    – Shivan-Drache

    19. August 2012 um 8:24

  • Das Gute an Anmerkungen, die @NotNull Und @Nullable Der Nachteil besteht darin, dass sie deutlich schlechter werden, wenn der Quellcode von einem System erstellt wird, das sie nicht versteht. Das Argument, dass der Code nicht portierbar ist, ist also möglicherweise ungültig. Wenn Sie ein System verwenden, das diese Anmerkungen unterstützt und versteht, erhalten Sie den zusätzlichen Vorteil einer strengeren Fehlerprüfung. Andernfalls erhalten Sie zwar weniger davon, Ihr Code sollte aber dennoch vorhanden sein Der Build ist einwandfrei und die Qualität Ihres laufenden Programms ist DIE GLEICHE, da diese Anmerkungen zur Laufzeit ohnehin nicht erzwungen wurden. Außerdem sind alle Compiler benutzerdefiniert 😉

    – Armen Michaeli

    20. März 2013 um 9:49 Uhr

  • Was bringt es, eine IllegalArgumentException auszulösen? Ich denke, NullPointerException wäre klarer und würde auch ausgelöst, wenn Sie die Nullprüfung nicht selbst durchführen. Ich würde entweder Assert oder gar nichts verwenden.

    – Axel

    9. August 2011 um 16:47 Uhr

  • Es ist unwahrscheinlich, dass jeder andere Wert als null akzeptabel ist. Sie könnten IllegalArgumentException, OutOfRageException usw. usw. haben. Manchmal ist dies sinnvoll. In anderen Fällen erstellen Sie am Ende viele Ausnahmeklassen, die keinen Mehrwert bieten, und verwenden dann einfach IllegalArgumentException. Es macht keinen Sinn, eine Ausnahme für Null-Eingaben und eine andere für alles andere zu haben.

    – myplacedk

    15. August 2011 um 12:26 Uhr

  • Eine Sicherheitslücke? Das JDK ist voller Code wie diesem. Wenn Sie nicht möchten, dass der Benutzer Stacktraces sieht, deaktivieren Sie sie einfach. Niemand hat angedeutet, dass das Verhalten nicht dokumentiert ist. MySQL ist in C geschrieben, wobei die Dereferenzierung von Nullzeigern ein undefiniertes Verhalten ist und nichts mit dem Auslösen einer Ausnahme zu tun hat.

    – fgb

    8. April 2013 um 0:39

  • throw new IllegalArgumentException("object==null")

    – Thorbjørn Ravn Andersen

    20. April 2013 um 23:35 Uhr

  • 1/2 Ich muss zustimmen, dass a IllegalArgumentException ist besser als eine einfache Vanille NPE für solche Situationen. Für mich ist ein NPE ein Hinweis darauf, dass irgendwo im Code ein Ausdruck, der zufällig null war, auf unsichere Weise dereferenziert wurde (vorausgesetzt, alle bekannten und deklarierten Vorbedingungen und Invarianten wurden erfüllt). Eine illegale Argumentausnahme OTH teilt mir mit, dass eine bekannte Vorbedingung oder Invariante nicht erfüllt wurde.

    – luis.espinal

    12. August 2016 um 17:28

Wow, ich hasse es fast, eine weitere Antwort hinzuzufügen, wenn wir 57 verschiedene Möglichkeiten haben, das zu empfehlen NullObject patternaber ich denke, dass einige Leute, die sich für diese Frage interessieren, vielleicht gerne wissen würden, dass ein Vorschlag für die Hinzufügung von Java 7 auf dem Tisch liegt „nullsichere Handhabung“– eine optimierte Syntax für die If-not-equal-null-Logik.

Das von Alex Miller gegebene Beispiel sieht so aus:

public String getPostcode(Person person) {  
  return person?.getAddress()?.getPostcode();  
}

Der ?. bedeutet, dass der linke Bezeichner nur dereferenziert wird, wenn er nicht null ist. Andernfalls wird der Rest des Ausdrucks als ausgewertet null. Einige Leute, wie Java Posse-Mitglied Dick Wall und die Wähler bei Devoxx Ich liebe diesen Vorschlag wirklich, aber es gibt auch Widerstand mit der Begründung, dass er tatsächlich eine stärkere Nutzung fördern würde null als Leitwert.

Aktualisieren: Ein offizieller Vorschlag für einen nullsicheren Operator in Java 7 wurde unter eingereicht Projektmünze. Die Syntax unterscheidet sich ein wenig vom obigen Beispiel, es handelt sich jedoch um dasselbe Konzept.

Aktualisieren: Der Vorschlag für einen nullsicheren Operator hat es nicht in Project Coin geschafft. Daher wird diese Syntax in Java 7 nicht angezeigt.

  • Ich denke, das ist falsch. Es sollte eine Möglichkeit geben, anzugeben, dass eine bestimmte Variable IMMER ungleich Null ist.

    – Thorbjørn Ravn Andersen

    26. Mai 2009 um 11:54

  • Update: Der Vorschlag macht Java7 nicht möglich. Sehen blogs.sun.com/darcy/entry/project_coin_final_fünf .

    – Boris Terzic

    29. August 2009 um 18:56

  • Interessante Idee, aber die Wahl der Syntax ist absurd; Ich möchte nicht, dass in jedem Gelenk eine Codebasis voller Fragezeichen steckt.

    – Rauben

    16. Mai 2012 um 11:51

  • Dieser Operator existiert in Groovigalso haben diejenigen, die es nutzen möchten, dies immer noch als Option.

    – Muhd

    15. Februar 2013 um 22:53

  • Das ist die genialste Idee, die ich je gesehen habe. Es sollte zu jeder sinnvollen Sprache der C-Syntax hinzugefügt werden. Ich würde lieber überall „Fragezeichen anheften“, als den ganzen Tag durch den Bildschirm voller Zeilen zu scrollen oder „Schutzklauseln“ auszuweichen.

    – Victor – Setzen Sie Monica wieder ein

    1. Okt. 2015 um 20:57

Wenn undefinierte Werte nicht zulässig sind:

Sie können Ihre IDE so konfigurieren, dass sie Sie vor einer möglichen Null-Dereferenzierung warnt. ZB in Eclipse, siehe Einstellungen > Java > Compiler > Fehler/Warnungen/Nullanalyse.

Wenn undefinierte Werte erlaubt sind:

Wenn Sie eine neue API definieren möchten, bei der undefinierte Werte sinnvoll sindverwenden Sie die Optionsmuster (kann aus funktionalen Sprachen bekannt sein). Es hat folgende Vorteile:

  • In der API wird explizit angegeben, ob ein Ein- oder Ausgang vorhanden ist oder nicht.
  • Der Compiler zwingt Sie, den Fall „undefiniert“ zu behandeln.
  • Option ist eine MonadeDaher ist keine ausführliche Nullprüfung erforderlich. Verwenden Sie einfach „map/foreach/getOrElse“ oder einen ähnlichen Kombinator, um den Wert sicher zu verwenden (Beispiel).

Java 8 verfügt über eine integrierte Optional Klasse (empfohlen); Für frühere Versionen gibt es beispielsweise Bibliotheksalternativen Guave‘S Optional oder FunctionalJava‘S Option. Aber wie bei vielen Mustern im funktionalen Stil führt die Verwendung von Option in Java (sogar 8) zu ziemlich vielen Boilerplates, die Sie mit einer weniger ausführlichen JVM-Sprache, z. B. Scala oder Xtend, reduzieren können.

Wenn Sie es mit einer API zu tun haben, die möglicherweise Nullen zurückgibt, kann man in Java nicht viel machen. Xtend und Groovy haben das Elvis-Operator ?: und das nullsicherer Dereferenzierungsoperator ?.aber beachten Sie, dass dies im Falle einer Nullreferenz null zurückgibt, sodass die ordnungsgemäße Behandlung von null lediglich „aufgeschoben“ wird.

  • Ich denke, das ist falsch. Es sollte eine Möglichkeit geben, anzugeben, dass eine bestimmte Variable IMMER ungleich Null ist.

    – Thorbjørn Ravn Andersen

    26. Mai 2009 um 11:54

  • Update: Der Vorschlag macht Java7 nicht möglich. Sehen blogs.sun.com/darcy/entry/project_coin_final_fünf .

    – Boris Terzic

    29. August 2009 um 18:56

  • Interessante Idee, aber die Wahl der Syntax ist absurd; Ich möchte nicht, dass in jedem Gelenk eine Codebasis voller Fragezeichen steckt.

    – Rauben

    16. Mai 2012 um 11:51

  • Dieser Operator existiert in Groovigalso haben diejenigen, die es nutzen möchten, dies immer noch als Option.

    – Muhd

    15. Februar 2013 um 22:53

  • Das ist die genialste Idee, die ich je gesehen habe. Es sollte zu jeder sinnvollen Sprache der C-Syntax hinzugefügt werden. Ich würde lieber überall „Fragezeichen anheften“, als den ganzen Tag durch den Bildschirm voller Zeilen zu scrollen oder „Schutzklauseln“ auszuweichen.

    – Victor – Setzen Sie Monica wieder ein

    1. Okt. 2015 um 20:57

Nur für diese Situation –

Es wird nicht überprüft, ob eine Variable null ist, bevor eine Equals-Methode aufgerufen wird (ein Beispiel für einen Zeichenfolgenvergleich unten):

if ( foo.equals("bar") ) {
 // ...
}

wird zu einem führen NullPointerException Wenn foo existiert nicht.

Das können Sie vermeiden, wenn Sie Ihre vergleichen StringEs ist so:

if ( "bar".equals(foo) ) {
 // ...
}

  • Ich stimme zu – nur in dieser Situation. Ich kann Programmierer nicht ausstehen, die das auf die nächste unnötige Ebene gehoben haben und schreiben, if (null != myVar)… sieht für mich einfach hässlich aus und hat keinen Zweck!

    – Alex Worden

    23. Mai 2011 um 18:14

  • Dies ist ein besonderes, wahrscheinlich am häufigsten verwendetes Beispiel einer allgemeinen guten Praxis: Wenn Sie es wissen, tun Sie es immer <object that you know that is not null>.equals(<object that might be null>);. Es funktioniert für andere Methoden als equals wenn Sie den Vertrag kennen und mit diesen Methoden umgehen können null Parameter.

    – Stef

    23. September 2011 um 1:20

  • Dies ist das erste Beispiel, das ich gesehen habe Yoda-Bedingungen das macht tatsächlich Sinn

    – Erin Drummond

    30. September 2013 um 19:37 Uhr

  • NullPointerExceptions werden aus einem bestimmten Grund ausgelöst. Sie werden ausgelöst, weil ein Objekt null ist, wo es nicht sein sollte. Es ist die Aufgabe des Programmierers, dieses Problem zu beheben, und nicht, das Problem zu verbergen.

    – Oliver Watkins

    12. Mai 2014 um 7:49

  • Das verbirgt nur das Problem. Was ist, wenn Sie verwenden foo später? Wenn eine Variable nicht null sein sollte, dies aber der Fall ist, muss Ihre App einen NPE erhalten, damit Sie als Entwickler den zugrunde liegenden Grund tatsächlich beheben können.

    – Arnab Datta

    26. November 2015 um 8:57 Uhr

1450680cookie-checkWie vermeide ich die Suche nach Nullen in Java?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy

Contact - Terms and Conditions - Privacy Policy