Umgang mit null

[Aldimann]

Hallo zusammen ,

wer kennt es nicht? Returnvalue null und Übergabeparameter null.

Ich hab jetzt schon öfter darüber Diskutiert und wollte eigentlich mal wissen ob es dazu Regelwerke gibt?

Sollte man null als Returnvalue durchgehen lassen? Wenn nicht, was sollt man dann zurück geben, wenn es kein vernünftiges Ergebnis gibt?

Und was ist mit null als Übergabeparameter? Erlaubt? Oder doch lieber eine zweite Methode mit einem Parameter weniger?

Bin gespannt auf die Antworten

Gruß

 

[The_S]

Kommt drauf an ;-) .

Wenn es Sinn macht,

null

zurückzugeben, dann darfst du das auch - ein Beispiel dafür ist eine Map, diese gibt

null

zurück, wenn der Key nicht gefunden wurde, was ich soweit auch sinnig finde. Wenn es allerdings bspw. in der Methode zu einem Fehler kam, und anstatt dass der Fehler weiter nach oben gereicht wird, einfach nur

null

zurück gegeben wird, finde ich das weniger sinnnig.

Genauso sieht es bei

null

als Übergabeparameter aus. Wenn es Sinn macht, dass man [c]null[/c] übergeben darf (simples Beispiel wäre ein Element, das im Konstruktor ein Vorgänger- und Nachfolger-Element erwartet und es einfach (noch) kein Nachfolger-Element gibt) und dieser [c]null[/c]-Parameter auch akzeptabel ist, es also später nicht darauf ohne Überprüfung zugegriffen wird, dann kann man das durchaus machen. Wenn es nicht möglich ist, wird ohnehin früher oder später eine NullPointerException geworfen ;-) .

Ob man dann für jedes Element, das evtl. [c]null[/c] sein könnte, eine eigene Methode schreibt, oder in der API-Dokumentation vermerkt, dass dieser und jener Parameter auch [c]null[/c] sein darf, kommt auch wieder auf den Fall an. Nehmen wir wieder die Map von oben. Eine Map, die als Value null akzeptiert, sollte (meiner Meinung nach) trotzdem nur eine Methode, nämlich [c]put(Object key, Object value)[/c] bereitstellen, und nicht noch zusätzlich die Methode [c]putNullValue(Object key)[/c].

Auf der anderen Seite biete ich bei Beans mit vielen Attributen meistens einen Konstruktor ohne Parameter, einen mit den wichtigsten Parametern und einen mit (fast) allen Parametern an.

Du siehst, es hängt immer vom Anwendungsfall ab.

 

[Java-Pelé]

Dass der Rückgabewert nicht null sein darf, ist eine klassische Nachbedingung. Prüfe doch, ob das Ding null werden kann.

assert returnValue != null;
return returnValue;

Schade, dass Java kein DbC der hohen Schule (Eiffel) beherrscht.

 

[Aldimann]

Danke erstmal!

Klar macht auch Sinn und die Map ist an der Stelle ein ziemlich gutes Beispiel.

Allerdings würde doch eine map folgendes z.B. nicht erlauben (habe es nicht getestet ):

map.put(null, "irgendwas");

, weil ein null-Key ja keinen Sinn machen würde.

Also kann man doch eigentlich mehr oder weniger festhalten, wenn es sich bei der Übergabe um eine Id oder etwas vergleichbares handelt (ein Key ist auch eine Id wenn man so will), dann sollte da kein null akzeptiert werden. Bei Optionalen Parametern kann man null akzeptieren, sollte es aber in der JavaDoc erwähnen.

Bei möglicher Rückgabe von null, in JavaDoc festhalten wann und warum.

Das war zumindest das was ich aus deinem Post verstanden hab oder hab ich da was falsch verstanden?

 

[The_S]

Allerdings würde doch eine map folgendes z.B. nicht erlauben (habe es nicht getestet ):

map.put(null, "irgendwas");

, weil ein null-Key ja keinen Sinn machen würde.

Warum nicht? Könnte man bspw. als eine Art Default-Wert ansehen. Gibt Maps, die erlauben das (bspw. HashMap) und Maps, die erlauben das nicht.

Also kann man doch eigentlich mehr oder weniger festhalten, wenn es sich bei der Übergabe um eine Id oder etwas vergleichbares handelt (ein Key ist auch eine Id wenn man so will), dann sollte da kein null akzeptiert werden.

eher weniger ;-) . Kommt eben ganz auf den Kontext an. null kann - situationsabhängig - genauso key sein. Genauso kann ein Nicht-Key oder Nicht-ID so wichtig sein, dass es nicht null sein darf.

Bei Optionalen Parametern kann man null akzeptieren, sollte es aber in der JavaDoc erwähnen.

Das sowieso - oder, wenn man ansonsten zu viele "nullable" Parameter hat, Methoden entsprechend überladen.

 

[Aldimann]

Warum nicht? Könnte man bspw. als eine Art Default-Wert ansehen. Gibt Maps, die erlauben das (bspw. HashMap) und Maps, die erlauben das nicht.

eher weniger ;-) . Kommt eben ganz auf den Kontext an. null kann - situationsabhängig - genauso key sein. Genauso kann ein Nicht-Key oder Nicht-ID so wichtig sein, dass es nicht null sein darf.

Das sowieso - oder, wenn man ansonsten zu viele "nullable" Parameter hat, Methoden entsprechend überladen.

Argh ;( das wäre doch soooo ne schöne Faustregel gewesen :/.

Also muss man in jeder Situation durchdenken inwiefern null Sinn macht und danach bestimmen ob nullable oder nicht...

 

[FArt]

null ist nicht Nichts! null ist zwar eine besondere Referenz, aber es ist eine Referenz und kann somit als solche verwendet werden.

 

[Ebenius]

Jedes mal nachdenken ist eine gute Idee. Null heißt halt kein Objekt und sollte überall dort erlaubt sein wo kein Objekt ein gültiger Zustand ist. Bei einer Methode [c]Node.setParent(Node)[/c] würde ich erwarten, dass [c]null[/c] akzeptiert wird, da kein Elternknoten der normale Zustand des Wurzelknoten eines Baumes ist. Eine Methode [c]readFromStream(InputStream)[/c] etwa sollte [c]null[/c] verbieten, da man von keinem InputStream nun mal nicht lesen kann.

Ebenius

 

[Landei]

Null ist das schwarze Loch des Typsystems, der Milliarden-Dollar-Fehler, die dunkle Seite der Macht, ein Krebsgeschwür, das Metastasen in deinen Code streut. 'nuf said.

 

[Aldimann]

Jedes mal nachdenken ist eine gute Idee. Null heißt halt kein Objekt und sollte überall dort erlaubt sein wo kein Objekt ein gültiger Zustand ist. Bei einer Methode [c]Node.setParent(Node)[/c] würde ich erwarten, dass [c]null[/c] akzeptiert wird, da kein Elternknoten der normale Zustand des Wurzelknoten eines Baumes ist. Eine Methode [c]readFromStream(InputStream)[/c] etwa sollte [c]null[/c] verbieten, da man von keinem InputStream nun mal nicht lesen kann.

Ebenius

Vom Prinzip her hast du recht aber bei sowas wäre es ja auch wieder so, wenn die Instanze keine Eltern hat warum dann explizit setzen?

 

[maki]

Suche mal nach Null Objekt, Landeis kommentar mag zwar extrem erscheinen, ist aber gar eigentlich richtig

 

[Ebenius]

Vom Prinzip her hast du recht aber bei sowas wäre es ja auch wieder so, wenn die Instanze keine Eltern hat warum dann explizit setzen?

Um zum Beispiel einen Knoten aus einem Baum heraus zu lösen und als eigenständigen Baum weiter zu benutzen.

Ebenius

 

[FArt]

Vom Prinzip her hast du recht aber bei sowas wäre es ja auch wieder so, wenn die Instanze keine Eltern hat warum dann explizit setzen?

Wer redet denn von unbedingt explizit setzen? Implizit, ohne die Notwendigkeit eine Unterscheidung treffen zu müssen...

 

[bygones]

Null ist das schwarze Loch des Typsystems, der Milliarden-Dollar-Fehler, die dunkle Seite der Macht, ein Krebsgeschwür, das Metastasen in deinen Code streut. 'nuf said.

Zitat vom hochgeschätzten, intelligenten Doug Lea..... "null sucks"

Jedes mal nachdenken ist eine gute Idee. Null heißt halt kein Objekt und sollte überall dort erlaubt sein wo kein Objekt ein gültiger Zustand ist. Bei einer Methode [c]Node.setParent(Node)[/c] würde ich erwarten, dass [c]null[/c] akzeptiert wird, da kein Elternknoten der normale Zustand des Wurzelknoten eines Baumes ist. Eine Methode [c]readFromStream(InputStream)[/c] etwa sollte [c]null[/c] verbieten, da man von keinem InputStream nun mal nicht lesen kann.

Ebenius

und warum dann nicht einfach ein NullObjekt anstatt null ? durch dieses Entweder-Oder-Vielleicht läuft man mehr Gefahr an falschen Stellen das falsche zu setzen. Würde man sich auf ein NullObjekt einigen wäre das Problem in keiner weise gegeben.

Und ja ich weiß, nicht immer ist ein NullObjekt nutzbar und ja.... alte Diskussion

 

[Ebenius]

und warum dann nicht einfach ein NullObjekt anstatt null ?

Wenn die Diskussion rein theoretischer Natur ist, bzw. eine völlig eigenständige Umgebung hätte, würde ich das in Erwägung ziehen. Da aber keine Sun-Klasse und keine der Bibliotheken die ich nutze diesen Ansatz verfolgt, sondern überall null der richtige Wert für nicht gesetzt ist, mache ich es so. Die Dinge so zu machen wie sie in der Umgebung üblich sind ist oft von Vorteil.

Aber in Stein gemeißelt ist da natürlich nichts.
Ebenius

 

[bygones]

Wenn die Diskussion rein theoretischer Natur ist, bzw. eine völlig eigenständige Umgebung hätte, würde ich das in Erwägung ziehen. Da aber keine Sun-Klasse und keine der Bibliotheken die ich nutze diesen Ansatz verfolgt, gehe ich von dem aus was der Java-Programmierer von meiner API erwarten würde. Aus dem Grund würde ich in einer Java-API eben null unterstützen weil das üblich ist.

nur weil es andere schlecht machen heisst ja nicht dass man dies auch tun muss... und ob der Verwender es "erwartet" hängt von der Dokumentation der API ab...
*kopfschüttel*

 

[Ebenius]

nur weil es andere schlecht machen heisst ja nicht dass man dies auch tun muss... [...]

Polemisch: Wenn die Briten in GB auf der linken Straßenseite fahren, ist das super. Wenn sie das in Deutschland auch tun würden, nur weil der Brite links nunmal besser findet, gibt's Chaos. Wie gesagt, polemisch.

[...] und ob der Verwender es "erwartet" hängt von der Dokumentation der API ab...
*kopfschüttel*

Was der Verwender erwartet hängt in erster Linie von seiner Gewohnheit ab. Es ist ja nicht so, dass ein Entwickler die API-Dokumentation jeder Methode die er verwendet gelesen hat. ;-) Die meisten Java-Entwickler würden erstmal erwarten, dass [c]setParent(null)[/c] funktioniert. Weil es eben üblich ist.

Ich will nicht missionieren, so sehe ich's eben.

Ebenius