NullPointerException: try oder if

[MKWWG]

Hallo erstmal!
Nehmen wir mal an, dass ich eine Methode habe, die mir ein TestObject zurück gibt.
Nun möchte ich gerne mit diesem TestObject weiter arbeiten.
Allerdings besteht die Gefahr, dass es auch null sein kann.
Dann soll ein anderes TestObject verwendet werden.

Jetzt frag ich mich, was sinnvoller ist:

to auf null mit if(to == null) prüfen

TestObject to = Object.get();
if(to == null)
to = Object.getAnderesObject();
to.getName();

oder
- mit try catch eventuell einen NullPointerException abfangen und in catch mit dem anderen Object weiter arbeiten.

TestObject to = null;
try{
Object.get().getName();
}
catch(NullPointerException e)
{
Object.getAnderesObject().getName();
}

Ich denke mal, dass die Version mit try länger dauert, wenn get() null liefert, als die über if.
Allerdings muss bei if jedes Mal to auf null getestet werden.
Wenn die Wahrscheinlichkeit nicht sehr hoch ist, dass to null ist, aber es dennoch nicht ausgeschlossen ist, kann ich dann try verwenden? Oder dauert das auch länger, wenn to nicht null ist?
Wann rentieren sich if und try?

 

[tfa]

Auf jeden Fall if!
Exceptions sind nicht fürs Flow-Control.
Siehe Effective Java, Item 39.

 

[Gast2]

Moin,

if(to == null)
to = Object.getAnderesObject();

das ist ganz schlecht ... für ungeübte Laien gibt das nur Probleme ... entweder

if(to == null) to = Object.getAnderesObject();

oder

if(to == null)
{
    to = Object.getAnderesObject();
}

in beiden Fällen ist der Programmfluß eindeutiger ... der letztere Fall ist aber zu empfehlen

hand, mogel

 

[Gast]

@mogel: Man sollte immer Klammern setzen, nicht nur als Laie. Das gibt mehr Übersicht und vereinfacht die Bearbeitung des Codes, weil man nur einen weiteren Befehl innerhalb der klammern schreiben muss

 

[Mark110]

Hmmm benutzt du den Functional Tester von IBM?

 

[MKWWG]

Also ich finde

if(to == null) to = Object.getAnderesObject();

nicht so eindeutig wie

if(to == null) 
    to = Object.getAnderesObject();

Aber ich finde, dass es jeder so machen sollte wie es für ihn am besten ist.
(Ok, ich hab bei meinem Beispiel die Leerzeichen vergessen.)
Dafür stellen die meisten IDEs ja die passenden Einstellungen bereit.

Kommt auch irgendwie auf die Anwendung an, denn das hier find ich alles andere als übersichtlich:

if(to == null)
{
   to = Object.getAnderesObject(1);
}

if(to == null)
{
   to = Object.getAnderesObject(2);
}

if(to == null)
{
   to = Object.getAnderesObject(3);
}

if(to == null)
{
   to = Object.getAnderesObject(4);
}

if(to == null)
{
   to = Object.getAnderesObject(5);
}

Da ist das hier irgendwie übersichtlicher:

if(to == null)
   to = Object.getAnderesObject(1);

if(to == null)
   to = Object.getAnderesObject(2);

if(to == null)
   to = Object.getAnderesObject(3);

if(to == null)
   to = Object.getAnderesObject(4);

if(to == null)
   to = Object.getAnderesObject(5);

Aber zurück zu meinem eigentlichen Problem - woraus sich die Frage mehr oder weniger gestellt hat:
Ich hab ein Objekt, das intern eine Liste mit Objekten hat.
Die Objekte kann man mit add() und remove() hinzufügen und löschen.
Dafür hab ich bis jetzt zwei verschiedene Wege gesehen:

1.) Die Liste wird im Constructor erzeugt.
2.) In add() und remove() wird überprüft ob eine Liste vorhanden ist und bei Bedarf erzeugt.

Kann man da etwas generell bevorzugen?

 

[FArt]

Kann man da etwas generell bevorzugen?

Nein.

 

[MKWWG]

Kann man da etwas generell bevorzugen?

Nein.

Und wann sollte man dann was verwenden?

 

[Gast]

in java würd ich so machen

if(to == null) {
   to = Object.getAnderesObject(1);
}
if(to == null) {
   to = Object.getAnderesObject(2);
}

dann sind alle Zweifel weg und wenn diu noch ein Sys.out einfügst oder was bist du immer am dem richtigen Ort

1 oder 2 hmm.

ich denke 1. vor allem wenn viele add da sind muss sonst immer wieder auf null getestet werden

 

[HLX]

Da ist das hier irgendwie übersichtlicher:

if(to == null)
   to = Object.getAnderesObject(1);

if(to == null)
   to = Object.getAnderesObject(2);

if(to == null)
   to = Object.getAnderesObject(3);

if(to == null)
   to = Object.getAnderesObject(4);

if(to == null)
   to = Object.getAnderesObject(5);

Wie wär´s mit:

int i = 1;
while(to == null && i < object.getSizeOfList())  { // getSizeOfList gibt die Größe der Liste zurück
    to = object.getAnderesObject(i);
}

Aber zurück zu meinem eigentlichen Problem - woraus sich die Frage mehr oder weniger gestellt hat:
Ich hab ein Objekt, das intern eine Liste mit Objekten hat.
Die Objekte kann man mit add() und remove() hinzufügen und löschen.
Dafür hab ich bis jetzt zwei verschiedene Wege gesehen:

1.) Die Liste wird im Constructor erzeugt.
2.) In add() und remove() wird überprüft ob eine Liste vorhanden ist und bei Bedarf erzeugt.

Kann man da etwas generell bevorzugen?

Ich würde sie im Konstruktor erzeugen.

 

[FArt]

Und wann sollte man dann was verwenden?

http://en.wikipedia.org/wiki/Lazy_initialization

 

[Marco13]

if(to == null)
   to = Object.getAnderesObject(1);

if(to == null)
   to = Object.getAnderesObject(2);

if(to == null)
   to = Object.getAnderesObject(3);

if(to == null)
   to = Object.getAnderesObject(4);

if(to == null)
   to = Object.getAnderesObject(5);

Finde ich auch nicht sooo toll - WENN schon kompakt dann so, dass man die menschlichen Fähigkeiten zur Mustererkennung ausnutzt

if(to == null) to = Object.getAnderesObject(1);
if(to == null) to = Object.getAnderesObject(2);
if(to == null) to = Object.getAnderesObject(3);
if(to == null) to = Object.getAnderesObject(4);
if(to == null) to = Object.getAnderesObject(5);

Man sieht auf einen Blick, dass alle Fälle gleich sind, und sich nur durch die Zahl am Ende unterscheiden. Aber für sowas extra die Codeformatierung bei der IDE ausschalten ist u.U. auch nicht so toll :?

 

[FArt]

if(to == null) to = Object.getAnderesObject(1);
if(to == null) to = Object.getAnderesObject(2);
if(to == null) to = Object.getAnderesObject(3);
if(to == null) to = Object.getAnderesObject(4);
if(to == null) to = Object.getAnderesObject(5);

Wenn ich so etwas im Code habe, würde ich sagen, dass ich da was falsch gemacht habe, oder?... ;-)