Bei den vorangehenden Methoden wird null als Sonderfall behandelt, und Ausnahmen vermieden. So sind etwa Objects.toString(null) oder Objects.hashCode(null) in Ordnung und es wird um null „herumgearbeitet.“ Das ist nicht immer sinnvoll, denn traditionell gilt es null als Argument und in den Rückgaben zu vermeiden. Es ist daher gut, als erstes in einem Methodenrumpf zu testen, ob die Argumente ungleich null sind – es sei denn, das ist unbedingt gewünscht.
Für diese Tests, dass Referenzen ungleich null sind, bietet Objects ein paar requireNonNull(…)-Methoden, die null-Prüfungen übernehmen und im Fehlerfall eine NullPointerException auslösen. Diese Tests sind dann praktisch bei Konstruktoren oder Settern, die Werte initialisieren sollen, aber verhindern möchten, dass null durchgeleitet wird.
Beispiel
Die Methode setName(…) soll kein name-Argument gleich null erlauben:
public void setName( String name ) {
this.name = Objects.requireNonNull( name );
}
Alternativ ist eine Fehlermeldung möglich:
public void setName( String name ) {
this.name = Objects.requireNonNull( name, "Name darf nicht null sein!" );
}
class java.util.Objects
§ static <T> T n requireNonNull(T obj)
Löst eine NullPointerException aus, wenn obj gleich null ist. Sonst liefert sie obj als Rückgabe. Die Deklaration ist generisch und so zu verstehen, dass der Parametertyp gleich dem Rückgabetyp ist.
§ static <T> T requireNonNull(T obj, String message)
Wie requireNonNull(obj), nur dass die Meldung der NullPointerException bestimmt wird.
§ static <T> T requireNonNull(T obj, Supplier<String> messageSupplier)
Wie requireNonNull(obj, message), nur kommt die Meldung aus dem messageSupplier. Das ist praktisch für Nachrichten, deren Aufbau teurer ist, denn der Supplier schiebt die Kosten für die Erstellung des Strings so lange hinaus, bis es wirklich zu einer NullPointerException kommt, denn erst dann ist die Meldung nötig. Neu in Java 8.