null-Prüfungen mit eingebauter Ausnahmebehandlung
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 eineNullPointerExceptionaus, wenn obj gleichnullist. 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)WierequireNonNull(obj), nur dass die Meldung derNullPointerExceptionbestimmt wird. -
static <T> T requireNonNull(T obj, Supplier<String> messageSupplier)WierequireNonNull(obj, message), nur kommt die Meldung aus demmessageSupplier. Das ist praktisch für Nachrichten, deren Aufbau teurer ist, denn derSupplierschiebt die Kosten für die Erstellung des Strings so lange hinaus, bis es wirklich zu einerNullPointerExceptionkommt, denn erst dann ist die Meldung nötig. Neu in Java 8.