Wie geht ihr mit null Referenzen und NullPointerExceptions um ? Diskussion

[Tikonteroga]

Hallo,

ich habe zurzeit ein keines Entwurfsproblem bei der JAVA Programmierung.

Zurzeit prüfe ich in allen öffentlichen Methoden jeden Parameter zuerst auf null. Ist einer oder mehrere der Parameter null werfe ich in der Methode eine IllegalArgumentException um eine spätere NullPointerException zu verhindern.

Da aber sowohl die IllegalArgumentException als auch die NullPointerException zu den Unchecked Exceptions gehören und zur Laufzeit eigentlich nicht sinnvoll behandelt werden können, sondern eine Korrektur des Codes erfordern (Programmierfehler !) stellt sich mir die Frame ob das Prüfen auf null in diesem Fall eigentlich nötig ist.

Es gibt natürlich Fälle in denen man auf null prüfen muss. Wenn man z. B. bei einer Hashtable mit einem key ein bestimmtes value abfrägt. Gibt es den Key nicht wird null als value zurückgegeben ...

Wie geht ihr denn mit diesem leidigen Thema um ?

Gruß

Tikonteroga

 

[Anime-Otaku]

Im Normalfall gehe ich davon aus, dass alle Parameter nicht null sind und daher keine explizite Null-Prüfung erfordern. Wenn man auch null als Parameter erwarten kann, muss dies natürlich entsprechend geprüft und im javadoc kenntlich gemacht werden.

Bei Membern von Objekten als Parameter, die nicht null sein dürfen, würde ich entweder vielleicht direkt angeben den Member als Parameter weiterzugeben oder hier eine entsprechende Fehlerbehandlung einbauen, welche aber nicht unbedingt zu einer Exception führen muss.

Bei einer HashTable muss man nicht null prüfen. Man kann auch einfach prüfen mit containsKey(Objekt), ob der key enthalten ist. Nicht destro-trotz ist die Prüfung mit null performanter (und mach ich auch lieber). Man hat nur dann ein Problem, wenn man auch null als Werte erlaubt, dann kommt man um die contains Methode nicht herum

 

[gorefest]

welchen sinn macht es, die eine exception mit der anderen auszutauschen?

mein lösungsweg :
optimistic. nullpointer exceptions werden niemals abgefangen, da es sich um einen programmierfehler handelt, wenn sie auftritt. wäre der nullwert kein fehler, hätte der entwickler auf null getestet und eine sinnvolle umverarbeitung darangehangen.

das geht noch weiter. wenn ich eine exception innerhalb eines geschäftsprozesses fange, dann werfe ich die gekapselt mit einer runtimeexception nach oben, um nicht überall exceptions definieren zu müssen; ausserdem interessiert es den aufrufer einer serviceschnittstelle foo() nicht wirklich, um eine daruntergelagerte hilfskomponente eine FileNotFoundException o.ä. wirft.

Generell gilt bei mir :

Exceptions werden NIEMALS als kontrollstrukturen verwendet. Das Fangen von Exceptions und die Reaktion darauf ist asozial teuer. Beispiel : mein kollege hat in einem datentransformationsprozess eine selbstgebaute Exception geworfen, wenn ein wert nicht gesetzt war. Diese wurde gefangen und mit einem alternativaufruf auf ein anderes modul substituiert. Nach Umstellung des Sourcecodes auf eine null-return/null-abfrage mimik, lief der code um sage und schreibe 40 mal schneller (6 sekunden statt vier minuten), da bei tausenden objekten das try-catch lief.

Grüße
gore