Das Thema der null Referenzen in Java, insbesondere als Rückgabewert von Methoden ist umstritten. Generell führt es zu einer erhöhten Gefahr von (aussagelosen) NullPointerExceptions.
An manchen stellen kann man diese einfach vermeiden: finder die eine Liste von Objekten zurückliefern sollten eine leere Ergebnismenge (die ohne Fehler zustande gekommen ist) nicht mit einem null; Rückgabewert signalisieren, sondern mit einer leeren Collection: "return List.EMPTY_LIST;".
An anderen Stellen ist die Vermeidung von null nicht immer unumstritten. Auf die Diskussion will ich mich hier jetzt garnicht einlassen. Deswegen habe ich hier eine einfache Policy - falls null Rückgabe Werte doch zulässig sein sollten:
Wenn schon null als Rückgabe Wert einer Methode, so darf dies nur passieren wenn:
Ein Negativbeispiel ist dies hier (der Code mit der Entscheidungsfindung ist hier deutlich übersichtlicher als bei größeren Methoden mit state variablen in der Praxis:
Mit einem expliziten return wird dies klarer, entweder (die von mir oftmals bevorzugte Early-Out Variante):
Oder eine if/else Cascade:
Wichtig ist dabei immer, dass im Code klar wird, was die Intention ist - also: soll null wirklich zurückgegeben werden oder wurde nur eine Fallunterscheidung vergessen. Wenn man sich dazu überwindet "return null;" zu schreiben, so ist es zugegebenermaßen manchmal etwas langatmiger, aber dafür eindeutig.
Eine Code Policy wie "jede Methode darf nur einen return punkt haben" ist übrigens nicht nur weil es dieses Idiom verbietet unsinnig. Das führt nur zu extremen Verschachtelungen. Dank Java finally gibt es dazu auch sehr selten Grund.
Übrigens versuche ich auch die returns innerhalb eines entsprechenden try/finally Blocks zu haben und vermeide "Alibi" returns am ende der Methode - die beschwichtigen nur erwünschte Warnings.
An manchen stellen kann man diese einfach vermeiden: finder die eine Liste von Objekten zurückliefern sollten eine leere Ergebnismenge (die ohne Fehler zustande gekommen ist) nicht mit einem null; Rückgabewert signalisieren, sondern mit einer leeren Collection: "return List.EMPTY_LIST;".
An anderen Stellen ist die Vermeidung von null nicht immer unumstritten. Auf die Diskussion will ich mich hier jetzt garnicht einlassen. Deswegen habe ich hier eine einfache Policy - falls null Rückgabe Werte doch zulässig sein sollten:
Wenn schon null als Rückgabe Wert einer Methode, so darf dies nur passieren wenn:
- im Javadoc erwähnt wird "@returns the Object requested or null"
- der null Wert im Code durch ein explizites "return null;" angegeben wird.
Ein Negativbeispiel ist dies hier (der Code mit der Entscheidungsfindung ist hier deutlich übersichtlicher als bei größeren Methoden mit state variablen in der Praxis:
public IThing getCarOrBike(int distance, Person p) {
IThing ret = null;
if (distance > 1000) {
ret = new Car();
ret.add(p);
}
if (distance > 100) {
ret = new Bike();
ret.add(p);
}
return ret; // BAD
}Mit einem expliziten return wird dies klarer, entweder (die von mir oftmals bevorzugte Early-Out Variante):
public IThing getCarOrBike(int distance, Person p) {
if (distance < 0 || p == null)
throw new IllegalArgumentException("You must specify a person and positive distance");
if (distance <= 100)
return null; // pedestrian
IThing ret;
if (distance > 1000) {
ret = new Car();
} else {
ret = new Bike();
}
ret.add(p);
return ret;
}Oder eine if/else Cascade:
/**
* Return Transportation for given distance.
* <P>
* This will return instances of Car or Bike. If the distance
* is short enough, null will be returned.
*
* @return null or new instance of Car or Bike with person added
*/
public IThing getCarOrBike(int distance, Person p) {
IThing ret = null;
if (distance > 1000) {
ret = new Car();
} else if (distance > 100) {
ret = new Bike();
} else {
return null; // pedestrian
}
ret.add(p);
return ret;
}Wichtig ist dabei immer, dass im Code klar wird, was die Intention ist - also: soll null wirklich zurückgegeben werden oder wurde nur eine Fallunterscheidung vergessen. Wenn man sich dazu überwindet "return null;" zu schreiben, so ist es zugegebenermaßen manchmal etwas langatmiger, aber dafür eindeutig.
Eine Code Policy wie "jede Methode darf nur einen return punkt haben" ist übrigens nicht nur weil es dieses Idiom verbietet unsinnig. Das führt nur zu extremen Verschachtelungen. Dank Java finally gibt es dazu auch sehr selten Grund.
Übrigens versuche ich auch die returns innerhalb eines entsprechenden try/finally Blocks zu haben und vermeide "Alibi" returns am ende der Methode - die beschwichtigen nur erwünschte Warnings.
Trackbacks
Trackback für spezifische URI dieses Eintrags
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
http://andyp-tw.blogspot.com/2008/08/returning-null-considered-dishonest.html
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-08(a)eckenfels.net
Read More
Suche
Verlinkung
Umfrage
Inhouse Coding?
Archive
Archive
Kommentare
Bernd Eckenfels zu DSL und der gefürchtete Parser
2008-08-12 16:59
Hmm Fowler lobt die einfachen DSLs
und sagt man soll dafür einen Parse
r bauen.
Wenn man das aber jetz
t nicht m [...]
2008-08-12 16:59
Bernd Eckenfels zu Arbeitsplatz Schönheit bei der AxelSpringer AG
2008-08-12 10:35
Leider keine Antworten, aber immerh
in hab ich grade nen Artikel gefund
en der oberflächlich beschreibt, wi
e sich Ma [...]
2008-08-12 10:35
Markus Kohler zu DSL und der gefürchtete Parser
2008-08-12 09:04
Hallo Bernd,
IMHO drückt sich Fow
ler davor eine DSL Workbench zu ben
utzen weil das der schwache Punkt v
on "exter [...]
2008-08-12 09:04
Bernd Eckenfels zu Null returns in Java
2008-08-12 03:23
More discussion:
http://andyp-tw
.blogspot.com/2008/08/returning-nul
l-considered-dishonest.html
2008-08-12 03:23
Bernd Eckenfels zu Terminkonflikt
2008-07-21 20:44
Hallo Beate,
ich war leider nich
t dort. Und mich ärgert es auch, da
ss so ein Verein es nicht auf die R
eihe beko [...]
2008-07-21 20:44
Beate zu Terminkonflikt
2008-07-18 21:17
Warst du bei der Vereinsgründung? W
ie wars? Ich finde aber auch nirgen
ds was drüber. Und angeschrieben ha
tte ich a [...]
2008-07-18 21:17
wolfgang bernsdorf zu Arbeitsplatz Schönheit bei der AxelSpringer AG
2008-07-15 19:00
Umstellung auf apple pc. So schöne
pc`s
kann es nicht geben, um gerne
bei Springer zu arbeiten (Spandau)
.
2008-07-15 19:00
Bernd Eckenfels zu Review: Team Beam
2008-07-01 04:35
Es gibt ein kleines Java Programm m
it dem man auf seinen Amazon S3 Acc
ount hochladen kann. Das tool kann
auch time [...]
2008-07-01 04:35
Christian Geisert zu Nostalgie in Sachen DatenFernÜbertragung
2008-06-12 14:47
grummel Registrierung grummel l
ahme Website grummel Download sch
lecht implementiert (falscher Datei
name, kei [...]
2008-06-12 14:47
Bernd Eckenfels zu Kündigungswellen trotz Rekordumsätze
2008-05-30 00:44
Fixed :) Danke Jennifer. Ich hatte
das Archiv gesehen aber da waren ir
gendwie nicht alle Artikel zu sehen
?
2008-05-30 00:44
Blog abonnieren
Blogsphere
Letzten Monat...
Mi, 16.07.2008Software Übersetzungen
Mi, 16.07.2008Terminkonflikt
Di, 15.07.2008Visual Virtualization
Do, 10.07.2008Google Lively
Mi, 09.07.2008Optimierungen beim Java Threading
Mi, 16.07.2008Terminkonflikt
Di, 15.07.2008Visual Virtualization
Do, 10.07.2008Google Lively
Mi, 09.07.2008Optimierungen beim Java Threading
Top Referers
www.google.de (26)
www.google.at (3)
209.85.135.104 (2)
extrabot.com (2)
www.google.ch (2)
search.live.com (1)
www.eckes.org (1)
www.google.hr (1)
www.keywordspy.com (1)
www.michaelreichart.de (1)
www.google.at (3)
209.85.135.104 (2)
extrabot.com (2)
www.google.ch (2)
search.live.com (1)
www.eckes.org (1)
www.google.hr (1)
www.keywordspy.com (1)
www.michaelreichart.de (1)
