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-09@eckenfels.net
Read More
Suche
Kategorien
Verlinkung
Eingehende Links
- google.com [76]
- www.google.de [5]
- www.google.de [4]
- www.google.de [3]
- www.google.de [3]
- www.google.de [2]
- www.google.de [2]
- www.google.de [2]
- www.google.de [2]
- www.google.de [2]
- www.google.de [1]
- www.google.de [1]
- www.google.de [1]
- www.google.de [1]
- www.google.de [1]
Umfrage
Wirtschaftskrise
Archive
Archive
Kommentare
2009-06-23 05:06
2009-06-16 12:27
2009-06-16 08:36
Bernd Eckenfels zu XSRF Schwachstelle auf dem ePetitions Server
2009-06-15 20:42
Bernd Eckenfels zu XSRF Schwachstelle auf dem ePetitions Server
2009-05-25 14:21
2009-05-22 09:55
Bernd Eckenfels zu XSRF Schwachstelle auf dem ePetitions Server
2009-05-21 00:54
2009-05-20 09:32
2009-05-19 21:45
Bernd Eckenfels zu Internetsperren nach Chinesischem Vorbild
2009-05-17 21:56
Blog abonnieren
Blogsphere
Letzten Monat...
Mi, 27.05.2009 Löschen statt verstecken: Es funktioniert!
So, 17.05.2009 Internetsperren nach Chinesischem Vorbild
Fr, 15.05.2009 XSRF Schwachstelle auf dem ePetitions Server
Mo, 11.05.2009 TweetUp Karlsruhe am 14.5
Mi, 06.05.2009 Presseerklärung der Piratenpartei
Top Referers
www.google.de (30)
rss.geekosphere.org (1)
villagevoice.backpage.com (1)
www.google.com (1)
www.newsgator.com (1)
rss.geekosphere.org (1)
villagevoice.backpage.com (1)
www.google.com (1)
www.newsgator.com (1)
Top Exits
www.heise.de (30)
www.golem.de (26)
www.oasis-open.org (22)
itblog.eckenfels.net (20)
www.readwriteweb.com (20)
www.microsoft.com (19)
twitter.com (18)
blogs.msdn.com (15)
epetitionen.bundestag.de (15)
www.die-gesundheitskarte.de (15)
www.golem.de (26)
www.oasis-open.org (22)
itblog.eckenfels.net (20)
www.readwriteweb.com (20)
www.microsoft.com (19)
twitter.com (18)
blogs.msdn.com (15)
epetitionen.bundestag.de (15)
www.die-gesundheitskarte.de (15)
Statistiken
280 Artikel wurden geschrieben
344 Kommentare wurden abgegeben
1144 Besucher in diesem Monat
66272 Besucher diese Woche
10 Besucher online
