null-Überprüfung

[at0m]

Hallo zusammen,

ich versuche innerhalb einer Methode A eine Methode B aufzurufen, die unter gewissen Umständen null zurückliefert. Wenn sie das tut, dann soll Methode A den Wert y zurückgeben, anderenfalls den Rückgabewert der Methode B.

Eine einfache Überprüfung des Rückgabewertes der Methode B in einer if-Anweisung funktioniert leider nicht, da bereits dessen Aufruf in einer NullPointerException endet, z.B.:

Beispiel:

if (methodeB(arg1) != null) {
    return methodeB(arg1);
} else {
    return y;
}

Löst man sowas mit in einer try-catch-Anweisung, z.B so?

try {
    return methodeB(arg1);
} catch (NullPointerException e) {
    return y;
}

Mir erscheint das nicht so elegant. Hat jemand einen Vorschlag?

 

[DarXun]

Das ist auch nicht die Lösung deines Problems.

Du möchtest y zurückgeben, wenn methodeB null liefert. Wenn methodeB aber mit einer NullPointerException abbricht, dann gibt sie ja eigentlich gar nichts zurück, somit dürftest du in dem Fall auch nicht y zurückgeben.

Ansonsten noch ein Tipp:
Schöner ist es nur eine return-Anweisung zu haben. Das ist übersichtlicher.

Also etwa sowas...

toReturn = methodeB(arg1);
if(toReturn == null) {
    toReturn = y;
}

return toReturn;

Den Datentyp von 'toReturn' weiß ich an dieser Stelle natürlich nicht.
Damit sparst du dir jedenfalls das zweite return-Statement und auch den erneuten Methodenaufruf (der kann natürlich auch gewünscht sein bei dir, ich hab aber mal gemutmaßt, dass er das nicht ist).

Einfacher ginge das ganze natürlich auch inline

toReturn = methodeB(arg1);
return toReturn != null ? toReturn : y;

 

[BlaueBohne]

ist ja klar, da if ja den Wert der Methode (Rückgabewert) überprüft. Ist dieser null wirft er ne exception.
Als würde man nichts mit nichts vergleichen. ^^

Und ja. Deshalb benutzt man try/catch. Ich finds auch nicht immer elegant und lässt sich auch manchmal umgehen.

Oder man macht es so wie mein Vorredner. :applaus:

 

[DarXun]

ist ja klar, da if ja den Wert der Methode (Rückgabewert) überprüft. Ist dieser null wirft er ne exception.

Nein. Es wird keine Exception geworfen. Sonst würde ja auch mein Weg nicht funktionieren.
Daher kann ich deiner Aussage "Deshalb benutzt man try/catch" auch nicht zustimmen.

 

[BlaueBohne]

Hab das ja auch auf seine Lösung bezogen. Bei Deiner wird das ja von vornherein ausgeschlossen. Hatte doch geschrieben, dass es sich manchmal umgehen lässt.

 

[Thallius]

Sorry aber ich verstehe gerade nicht wo jetzt der Unterschied liegt zwischen

if (methodeB(arg1) != null) {
    return methodeB(arg1);
} else {
    return y;
}

und

toReturn = methodeB(arg1);
if(toReturn == null) {
    toReturn = y;
}
 
return toReturn;

Beides macht genau das selbe. Wenn der Aufruf

methodeB(arg1)

eine Excpetion wirft, dann tut sie das in beiden Beispielen und beide werden ohne try/catch nicht funktionieren.

Gruß

Claus

 

[coco07]

Moin Jungs,

also erstmal sei gesagt, dass beide Fälle funktionieren.

Methode A:

if (methodeB(arg1) != null) {
    return methodeB(arg1);
} else {
    return y;
}

Sehr unschön, da man 2 return-Anweisungen hat und "methodeB(args)", wenn sie nicht null liefert 2 mal ausgeführt wird(was bei größeren Berechnungen nicht gerade performancesparend ist).

Methode B:

toReturn = methodeB(arg1);
if(toReturn == null) {
    toReturn = y;
}
 
return toReturn;

Tut genau das gleiche wie Methode A, ist aber dennoch viel übersichtlicher.

Und eine NPE wird nur geworfen, wenn du auf einer Referenz, welche kein Objekt referenziert eine Methode aufrufst.
Try u. Catch solltest du nur benutzen, um "Ausnahmesituationen" zu behandeln, nicht aber um die Schwachstellen im Code wieder auszubessern. Und mit Ausnahmesituationen meine ich z.B. wenn du in eine Datei schreiben möchtest, diese aber nicht da ist, wo sie eigentlich sein sollte(Woher sollte dein Code das auch wissen?)...

Grüße coco07!

 

[Thallius]

Moin Jungs,

also erstmal sei gesagt, dass beide Fälle funktionieren.

Methode A:

if (methodeB(arg1) != null) {
    return methodeB(arg1);
} else {
    return y;
}

Sehr unschön, da man 2 return-Anweisungen hat und "methodeB(args)", wenn sie nicht null liefert 2 mal ausgeführt wird(was bei größeren Berechnungen nicht gerade performancesparend ist).

Methode B:

toReturn = methodeB(arg1);
if(toReturn == null) {
    toReturn = y;
}
 
return toReturn;

Tut genau das gleiche wie Methode A, ist aber dennoch viel übersichtlicher.

Grüße coco07!

Würde ich widersprechen. Jeder halbwegs schlaue Compiler/Interpreter wird die Methode nicht zweimal ausführen sondern das optimieren. Dadurch dürfte Bespiel 1 klar performanter sein, da man sich das anlegen einer zusätzlichen variablen auf dem Stack spart.

Was die Übersichtlichkeit angeht, dass ist Geschmacksache.

Gruss

Claus

 

[coco07]

Folgender Quellcode:

public class Main {
	
	private static byte aufrufe;
	
	public static void main(String[] args){
		if(gibNotNullZurück() != null){
			gibNotNullZurück();
		}
		System.out.println(aufrufe);
		
	}
	
	private static Object gibNotNullZurück(){
		aufrufe++;
		return new Object();
	}

}

gibt in meiner Konsole 2 aus.

Und davon ausgehend, dass der Interpreter gar nicht "wissen" kann, ob wirklich das "gleiche" Objekt zurückgegeben wird, da es z.B. auch von laufzeitspezifischen Dingen wie der Zeit abhängen kann, würde ich das sogar als falsch bezeichnen.

grüße coco07!

 

[nvidia]

[...]

if (methodeB(arg1) != null) {
    return methodeB(arg1);
} else {
    return y;
}

Java 8

... meineFunktion(...){
    return Optional.ofNullable(methodeB(arg1)).orElse(y);
}

 

[at0m]

Vielen Dank für die vielen Antworten!

Ich beziehe mich im Folgenden auf dies Methode

toReturn = methode(arg1);
if (torReturn == null) {
    toReturn = y;
}
return toReturn;

Ohne sich erst mal Gedanken über die Performance zu machen.

Das Problem an dieser Stelle ist, dass die NPE bereits in Zeile 1 auftritt. Bereits der Aufruf der Methode methode(arg1) endet in einer NPE. Somit wird gar nicht erst in die if-Anweisung gesprungen, da das Programm abbricht.

 

[Joose]

Das Problem an dieser Stelle ist, dass die NPE bereits in Zeile 1 auftritt. Bereits der Aufruf der Methode methode(arg1) endet in einer NPE.

Sprich es kann vorkommen das "methode" eine NullPointer verursacht. Daher müsstest du noch ein try/catch hinzufügen beim Aufruf

 

[nvidia]

Sprich es kann vorkommen das "methode" eine NullPointer verursacht. Daher müsstest du noch ein try/catch hinzufügen beim Aufruf

Wozu? Im ursprünglichen Post schreibt er

"[...] Methode A eine Methode B aufzurufen, die unter gewissen Umständen null zurückliefert."

Dann wäre es doch angebrachter dass er das Argument arg in methodeB(arg) auf != null überprüft und null zurückgibt falls == null.

 

[Joose]

"[...] Methode A eine Methode B aufzurufen, die unter gewissen Umständen null zurückliefert."

Stimmt, aber leider stehts nirgends geschrieben wie reagiert werden soll wenn Methode B eine Exception verursacht.
Natürlich kann man hier nicht den Rückgabewert von Methode B zurückgeben, da durch die Exception dieser nicht "existiert".
Aber wäre es dann auch richtig "y" zurückzugeben? null != Exception

Dann wäre es doch angebrachter dass er das Argument arg in methodeB(arg) auf != null überprüft und null zurückgibt falls == null.

Wäre eine Möglichkeit, leider muss "arg" nicht die Ursache für die Exception sein.

 

[Thallius]

Der Fehler liegt in Methode B. Um es richtig zu machen, müßte man Methode B umschreiben, dass sie keine Exception mehr wirft sondern null zurück gibt wenn ein Fehler auftritt. Die Frage ist jetzt ob dser TO das kann oder ob die Methode B so unveränderbar vorgegeben ist.

Gruß

Claus

 

[at0m]

Die Methode B ist leider unveränderbar. Damit bleibt nur die Möglichkeit mit try-catch, richtig?

 

[Thallius]

Jupp

 

[at0m]

OK, dann ein großes Dankeschön an alle Beteiligten!

 

[ceving]

Hallo zusammen,

ich versuche innerhalb einer Methode A eine Methode B aufzurufen, die unter gewissen Umständen null zurückliefert. Wenn sie das tut, dann soll Methode A den Wert y zurückgeben, anderenfalls den Rückgabewert der Methode B.

Eine einfache Überprüfung des Rückgabewertes der Methode B in einer if-Anweisung funktioniert leider nicht, da bereits dessen Aufruf in einer NullPointerException endet, z.B.:

Beispiel:

if (methodeB(arg1) != null) {
    return methodeB(arg1);
} else {
    return y;
}

Löst man sowas mit in einer try-catch-Anweisung, z.B so?

try {
    return methodeB(arg1);
} catch (NullPointerException e) {
    return y;
}

Mir erscheint das nicht so elegant. Hat jemand einen Vorschlag?

Ja man löst es mit try/catch aber nicht so. ;-)

Die Prüfung ob der Rückgabe-Wert von methodeB null ist, fehlt. Am besten machst du dir einen Wrapper für methodeB, der die NullPointer-Exception fängt und dafür null zurück gibt. Danach kannst du dann null prüfen und y zurück geben.

Aber zur Info: NullPointer-Exceptions sind Programmierfehler und sollten behoben werden. Es macht nur bedingt Sinn, um sie herum zu programmieren.

 

[at0m]

Hallo ceving,

ich habe nun eine Methode mit einem booleschen Rückgabewert geschrieben. Beispiel:

public boolean isAvailable(arg1) {
    try {
        methodeB(arg1);
        reurn true;
    } catch(NullPointerException e {
        return false;
    }
}

In der Hauptmethode (siehe erster Post) habe ich dann folgendes implementiert:

if (isAvailable(arg1)) {
     variable = methodeB(arg1);
}

Kurz zum Hintergrund. MethodeB ist Teil eines Frameworks, welches ich verwende. Sie extrahiert einen bestimmten Wert aus einem gegebenen Objekt. Dieser Wert ist innerhalb des Objektes aber nicht immer vorhanden. "wert" soll "var" also nur zugeordnet werden, wenn er auch vorhanden ist.

Das wäre so die Lösung, oder?

 

[JavaMeister]

Nein, auf keinen fall wäre das so die Lösung.

Wenn der Wert von arg1 nicht durch MethodeB ermittelt werden kann, dann sollte sie Null zurück geben und nicht eine NPE werden.

Ohne den Thread gelesen zu haben, könnte es sein, dass diese Methode sowas macht Dann ist diese schlecht implementiert. In dem fall baust du auf einem wackeligen Gerüst weiteres auf. Das kann irgendwann in die Hose gehen.

Exception sollten nie für die Steuerung des programmablaufs verwendet werden.

Ok. Wenn MethodeB eine exception wirft, dann ist das so und dann hast du keine andere Wahl.

 

[Thallius]

Und warum fragst du nicht einfach ab ob das benötigte Object überhaupt da ist bevor du MethodeB aufrufst? Das wäre zu einfach oder was?

Gruß

Claus

 

[ceving]

Hallo ceving,

ich habe nun eine Methode mit einem booleschen Rückgabewert geschrieben. Beispiel:

public boolean isAvailable(arg1) {
    try {
        methodeB(arg1);
        reurn true;
    } catch(NullPointerException e {
        return false;
    }
}

In der Hauptmethode (siehe erster Post) habe ich dann folgendes implementiert:

if (isAvailable(arg1)) {
     variable = methodeB(arg1);
}

Das wäre so die Lösung, oder?

Ich würde es so machen:

// -*- compile-command: "javac tmp.java; java tmp" -*-

// Mal ein komplettes Beispiel
class tmp
{
    // Du benutzt methodeB
    public static String use_methodeB (String arg1)
    {
	String y = "y";

	// Das war dein Ausgangsbeispiel:

	if (methodeB(arg1) != null) {
	    return methodeB(arg1);
	} else {
	    return y;
	}
    }

    // Problem war, dass methodeB unsicher ist, weil sie eine
    // Null-Pointer-Exception zurück liefern kann.  Wie ich gesagt
    // hatte, muss das nicht ihre Schuld sein.  Es kann auch sein,
    // dass arg1 falsch initialiert ist.  Somit wäre die richtige
    // Lösung, arg1 richtig zu initialisieren.
    public static String methodeB (String arg1)
    {
	// Mockup
	throw new NullPointerException ();
    }

    // Alternativ kann man eine Wrapper-Version von methodeB
    // schreiben, die sich genauso verhält wie methodeB aber die
    // Exception fängt und statt dessen null zurück gibt.
    public static String safe_methodeB (String arg1)
    {
	try {
	    return methodeB(arg1);
	}
	catch (NullPointerException ex) {
	    return null;
	}
    }

    // Und anstatt der Original-Methode benutzt du in deinem Code die
    // sichere Variante.
    public static String safe_use_methodeB (String arg1)
    {
	String y = "y";

	// Eine Methode zweimal aufzurufen ist meist keine so gute
	// Idee in Java, weil Java Seiteneffekte liebt.  Sowas macht
	// man nur in funktionalen Sprachen.  In Java muss der
	// Rückgabewert gesichert werden.

	String result = safe_methodeB(arg1);
	return result == null ? y : result;
    }

    public static void main (String[] args)
    {
	System.out.println(safe_use_methodeB ("x"));
    }
}

Anstatt von String musst du deine Typen verwenden.

 

[Harry Kane]

Nein, auf keinen fall wäre das so die Lösung.
Wenn der Wert von arg1 nicht durch MethodeB ermittelt werden kann, dann sollte sie Null zurück geben und nicht eine NPE werden.
Ohne den Thread gelesen zu haben, könnte es sein, dass diese Methode sowas macht Dann ist diese schlecht implementiert. In dem fall baust du auf einem wackeligen Gerüst weiteres auf. Das kann irgendwann in die Hose gehen.
Exception sollten nie für die Steuerung des programmablaufs verwendet werden.
Ok. Wenn MethodeB eine exception wirft, dann ist das so und dann hast du keine andere Wahl.

Zum ersten Teil des Beitrags: da der TO keine Kontrolle über methodeB hat, kann er auch nicht beeinflussen, was sie macht, und wann sie eine NPE wirft oder nicht oder wie oder was.
Zum letzten Satz (der nach dem OK): Bedeutet das jetzt, daß du die zuletzt vom TO genannte Strategie für gut hältst? Ich finds wegen des doppelten Aufrufs von methodeB zumindest unelegant.

Und warum fragst du nicht einfach ab ob das benötigte Object überhaupt da ist bevor du MethodeB aufrufst?

Wäre eine Möglichkeit, leider muss "arg" nicht die Ursache für die Exception sein.

Diesen Punkten sollte man vielleicht mal nachgehen. Wenn "arg" tatsächlich die Ursache für die NPE ist (wobei Joose natürlich recht hat, daß es auch irgendwas anderes sein kann), und wenn sich einfach feststellen läßt, welche Typen von "arg" methodeB dazu bringen eine NPE zu werfen (z. B. ob es damit zusammenhängt, ob arg null order nicht null ist), dann sollte das natürlich vorher überprüft werden (so wie von Thallius ev. vorgeschlagen, obwohl er wahrscheinlich auf etwas anderes hinaus wollte)
@atOm: Kannst du das bitte mal überprüfen? Was sagt überhaupt die API Dokumentation (sofern vorhanden) darüber, unter welchen Umständen methodeB eine NPE wirft.
Wenn methodeB auch bei einem non-null arg1 eine NPE wirft, würde ich a) es so machen wie der TO zuletzt vorgeschlagen hat und b) dem Programmierer von methodeB eine Verbesserungsvorschlag zukommen lassen.

 

[at0m]

Leute, ich hatte einen gewaltigen Denkfehler in meiner Implementierung (frameworkbezogen).
Ich habe es nun so gelöst, dass ich eine Klasse erstellt habe, die das betroffene Interface des Frameworks implementiert und die kritische Methode überschreibt. Dort findet dann die null-Überprüfung statt. Auf den try-catch-Block kann ich nun verzichten.

Ich danke euch allen für die tatkräftige Unterstützung, die mich letztendlich zur Lösung geführt hat.