Weshalb man Parameter auf Gültigkeit prüfen sollte

[AlArenal]

In seinem Weblog verrät uns hoskinator heute, warum man Parameter auf Gültigkeit überprüfen sollte. Ich spiele den Ball mal einfach weiter, für uns Deutsch-Sprecher

Josh Bloch führt in seinem Buch "Effective Java" diesen Tipp unter der Nummer 23. Man sollte sich mal die Mühe machen durchzugehen, warum man es tun sollte, ob man es wirklich tun sollte und welche Konsequenzen sich daraus ergeben.

Man kann beispielsweise argumentieren, dass der Aufrufer sicherzustellen hat, zulässige Paramterwerte zu übergeben. Was zulässig ist und was nicht, ist dabei per JavaDoc zu dokumentieren. Mit diesem Wissen ausgestattet können wir uns zurücklehnen und sagen "Wer sich nicht dran hält, ist selber schuld.".
Stellt sich die Frage, ob man es sich wirklich so einfach machen sollte, die Verantwortung für die korrekte Funktion des eigenen Codes an andere abzuschieben. Zumal es ja auch sein kann, dass man selbst bei der Benutzung der eigenen Methoden Fehler einbaut.

Generell sollten Fehler bei der Programmausführung so früh als möglich als solche in Erscheinung treten (fail-fast), so dass sie nicht zu Folgefehlern führen, die evtl. noch schwerwiegender sind. Dies vereinfacht auch das Debugging, da die Fehlerkette kürzer ist, an der entlang man sich zur Ursache hangelt. Die Idee hinter dem Ganzen wurde mir schnell klar. Bewusst oder unbewusst bin ich vor einiger Zeit schon dazu übergegenagen Parameter zu checken, auch wenn ich das vermutlich nicht immer und an jeder Stelle tue (Ich gelobe Besserung!). Besonders in meinem ab und an zu schreibenden PHP-Code checke ich recht viel, da diesen lose typisierenden Skriptsprachen nicht so recht zu trauen ist.

Bisher habe ich es so gehandhabt, dass ich fehlerhafte Parameter lediglich protokolliert und die Methode daraufhin mit einem "return" oder "return null" beendet habe. Allerdings interessierte mich, wie andere dies handhaben und mit welcher Begründung. So wurde ich auf einen weiteren Blog-Eintrag aufmerksam gemacht und musste feststellen, dass ich bisher nur sehr selten selbstständig Exceptions geworfen habe. Stattdessen habe ich festgeelgt, dass im Falle eines Fehlers eine Methode "null" zurückliefert. Das krabllet dann die Nahrungskette soweit nach oben, bis schlussendlich doch irgendwo eine Exception herauskommt, oder ein nicht gewünschtes Verhalten auftritt.

Daher werde ich wohl demnächst mit meinen neuen Freunden einen trinken gehen, die da heißen NullPointerException, IllegalArgumentException und IndexOutOfBoundsException. Auf eine gute Freundschaft, Prost!


Links:
- Why you should check method parameters for validity
- Where should you check for NullPointerExceptions

 

[foobar]

Stattdessen habe ich festgeelgt, dass im Falle eines Fehlers eine Methode "null" zurückliefert. Das krabllet dann die Nahrungskette soweit nach oben, bis schlussendlich doch irgendwo eine Exception herauskommt, oder ein nicht gewünschtes Verhalten auftritt.

Das versuche ich zu vermeiden.

Ich prüfe Parameter in kritischen methoden oft auf Gültigkeit und werfe dann IllegalArgument oder IllegalStateExceptions mit aussagekräftigen Fehlermeldungen.
In einer Methode prüfe ich z.b. ob der übergeben in einem Range zwischen 0 und 255 liegt und werfe ansonsten eine IllegalargumentException mit dem Hinweise, daß nur 0-255 erlaubt ist. Das macht das Leben etwas eträglicher, weil man sofort sieht wo der Fehler liegt

Viele Grüße
foobar

 

[AlArenal]

Ich warte nur noch auf nen C-Gast, der nun wieder meckert wegen der Performance..

 

[foobar]

Ich warte nur noch auf nen C-Gast, der nun wieder meckert wegen der Performance..

*ggg* Tja, auch Software unterliegt dem Gesetz der Polarität. Jede Entscheidung hat ihre Vor- und Nachteile.

BTW Ich halte Performanceoptimierungen wie Getter und Setter durch direkten Zugriff auf die Member zu ersetzen für Unsinn. Bei welchen Anwendungen soll man denn da einen Unterschied feststellen?

 

[Kola]

Ja, das mit den Exceptions sollte man konsequent durchziehen. Wenn man das weiterdenkt, dann sollte mir Eclipse eigentlich für eine nicht-implementierte Methode keinen Returnwert angeben, sondern eine RuntimeException werfen.
Beispiel (für eine void-Funktion. Für den Returnwerttyp "Object" würde Eclipse "return null;" generieren):

	public void initializeRelationships() {
		// TODO Auto-generated method stub

	}

würde dann zu:

	public void initializeRelationships() {
		// TODO Auto-generated method stub
                                throw new RuntimeException("not implemented");
	}

 

[AlArenal]

@foobar:
Ich halte es mit dem Grundsatz, dass die einzigen public Variablen final sein müssen. Alles andere ist ein Albtraum, wenn man später was ändern muss. Eine interessante Frage ist auch, welchen Typ solche Konstanten haben sollten. Nehmen wir an du schreibst eine Lib und definierst öffentliche String-Konstanten. Änderst du diese nachträglich, musst du auch die Anwendungen, die die Lib verwenden neu kompilieren, was bei Objekt-Instanzen anstatt der Strings nicht der Fall wäre.

@kola:
Sind diese Methodenrümpfe nicht in Vorlagen defniniert, die man ändern kann? In Netbeans bin ich mir sehr sicher, dss es so ist. Hatte da neute noch so ein Template in den Fingern.

 

[AlArenal]

@kola:
Sind diese Methodenrümpfe nicht in Vorlagen defniniert, die man ändern kann? In Netbeans bin ich mir sehr sicher, dss es so ist. Hatte da neute noch so ein Template in den Fingern.

Window -> Preferences -> Java -> Code Style -> Code Templates -> Method body