(02.02.04 16:28)

Eine wichtige Programmierregel besagt, dass Programme so entworfen sein sollten, dass Fehler so früh wie möglich erkannt werden können. Dahinter steht die Überlegung, dass es umso einfacher ist, die Ursache für einen Fehler zu finden, je näher Ursache und Wirkung räumliche und/oder zetilich zusammen fallen.

Ein anschauliches Beispiel bietet die Prüfung von Argumenten einer Methode und das Werfen von entsprechenden Exceptions. Schauen wir uns dazu zwei extreme Positionen zweier Java-Entwickler an:

Mauro prüft jeden Parameter in einer Methode auf seine Gültigkeit und wirft entsprechende IllegalArgumentExceptions. Patrick verzichtet dagegen vollständig auf entsprechende Prüfungen.

Welches Vorgehen ist das bessere? Auf den ersten Blick scheint Mauro die Vorderung nach räumlicher und/oder zeitlicher Nähe besser zu erfüllen als Patrick. Schliesslich wirft er in seinem Code eine Exception, sobald er auf ein ungültiges Argument stösst. In Patricks Code kommt es dagegen häufig vor, das sich ein ungültiger Wert für einen Paramter erst wesentlich später bemerkbar macht. Das treibt seine Kollegen mit schöner Regelmässigkeit zur Weissglut. Patrick vertritt die Meinung, dass es sich nicht lohnt, Parameter auf ihre Gültigkeit zu testen, da es spätestens bei ihrer Verwendung zu einem Fehler kommt, sollte der Wert ungültig sein. Diese Überlegung ist grundsätzlich richtig, sofern wir spätestens durch frühstens ersetzen. Patricks Prüfung erfolgt implizit durch die Verwendung des Parameters . Mauro setzt dagegn auf eine explizite Prüfung vor der Verwendung.

Wer hat nun also Recht? Ist es Mauro oder Patrick? Die Antwort lautet: Es kommt darauf an.

Schauen wir uns dazu zwei Beispiele an

// // Beispiel 1 // public void accept(Visitor aVisitor) { aVisitor.visit(this); } // // Beispiel 2 // public void setFilter(IFilter aFilter) { m_Filter = aFilter; reset(); } public boolean hasNext() { boolean result = false; while (m_iter.hasNext() && !result) { m_next = m_iter.next() result = m_Filter.accept(m_next()); } if (!result) { m_next = null; } return result; }

Im ersten Beispiel können wir uns auf die implizite Prüfung durch Verwendung verlassen, da die Übergabe von null unmittelbar zu einer NullPointerException führt, deren Ursache leicht auszumachen ist. Anders sieht es im zweiten Beispiel aus. Hier macht die explizite Prüfung Sinn, da die Verwendung des Argumentes nicht unmittelbar erfolgt. Es kommt hier erst in der Methode hasNext zu einem Fehler. Zwar ist es auch in diesem Beispiel immer noch relativ einfach, den Fehler aufzuspüren. Aber es erfordert bereits mehr Aufwand, die Ursache für das verzögerte Auftreten des Fehlers zu lokalisieren.

Daraus können wir die folgende einfache Regel formulieren:

Die Argumente einer Methode sollten immer dann explizit auf ihre Gültigkeit geprüft werden, wenn Fehler aufgrund ungültiger Werte erst verzögert, d.h. nicht im Rahmen der aufgerufenen Methode auftreten.

Die set-Methode im zweiten Beispiel würden wir somit wie folgt ergänzen:

public void setFilter(IFilter aFilter) { if (aFilter == null) { throw new IllegalArgumentException( "aFilter cannot be null"); } m_Filter = aFilter; reset(); }

-nemo :-)

Über diesen Eintrag diskutieren.

Zugriffe heute: 1 - gesamt: 4063.