Exceptions und so ... Gedankenspiele

[bernau]

Der Vortrag von Bernd Ua, bei den letzten Delphi-Tagen, hat mich veranlasst etwas mehr über Exception-Behandlung nachzudenken. (Danke übrigens für den tollen Vortrag)

Exceptions haben im Laufe der Zeit bei mir eine Evolution erlebt.

Früher Exceptions tot geschwiegen.

Delphi-Quellcode:

try
  // hier der Code mit Fehlern
except
  // Hier überhaupt nichts drin
end;
  // Und blos kein Finally (würg)

Heute rege Benutzung von Exceptions.

Aber es gibt ja immer noch was zu lernen und zum Nachdenken. Dank dem Vortrag von Bernd.

***************************************

Genug der Worte. Hier mal eine Frage.

Oft wiederholen sich Exceptions und die dazu vorherige Auswertung.

Delphi-Quellcode:

if not inrange(aIndex,MinValue,MaxValue) then
  Raise Exception.create('Index out of range: Index='+inttostr(aIndex)+' MinValue='+inttostr(MinValue)+' MaxValue='+inttostr(MaxValue));

Spricht irgendwas dagegen dies in einer Funktion zusammen zu fassen?

Delphi-Quellcode:

Procedure RaiseIfNotInRange(aIndex:Integer;aMinValue:Integer;aMaxValue:Integer);
begin
if not inrange(aIndex,aMinValue,aMaxValue) then
  Raise EMyOutOfRangeException.create('Index out of range: Index='+inttostr(aIndex)+' MinValue='+inttostr(aMinValue)+' MaxValue='+inttostr(aMaxValue));
end;

Dann im Code nur noch folgendes aufrufen.

  RaiseIfNotInRange(aIndex,3,10);

Ist doch viel weniger Tipparbeit. Spricht etwas dagegen das so zu machen? Leidet die Lesbarkeit? Ich weis, ist ne banale Frage. Einfach machen und gut ist. Aber die Meinungen dazu interessieren mich schon.

[Der schöne Günther]

So ein Konstrukt findest du in der RTL ziemlich oft, und nicht nur dort. Meistens aber nicht mit "RaiseIfXYZ(..)" sondern "CheckXYZ(..)".
Vor allem wenn du, beispielsweise eine Zahl, nicht nur auf Grenzbereiche prüfen willst, sondern noch andere Dinge zum Tragen kommen. Beispielsweise nur grade Zahlen oder was auch immer.


Das geht schon leicht an der eigentlichen Frage vorbei, aber wenn du wirklich glaubst deine eigene EMyOutOfRangeException zu erfinden und nicht die bereits bestehende EArgumentOutOfRangeException (die sich von EArgumentException ableitet), dokumentier das bitte! Als Benutzer möchte ich immer sehen welche Exceptions ich zu erwarten habe.

PS: Ich war leider nicht bei seinem Vortrag, höre aber immer nur Lobpreisungen über Herrn Ua. Kann mir einer eine kurze Zusammenfassung geben was gepredigt wurde?

[JasonDX]

Ich finde hier die Idee der Preconditions aus Guava recht praktisch. Diese orientieren sich aber primär an den Exceptions, die sie werfen (InvalidArgumentException, NullPointerException, IllegalStateException, etc.). Der Kontext der Prüfung kann dann in die Message der Exception verpackt werden.

Etwas Delphi-ähnliches ließe sich auch recht leicht realisieren, wobei ich mich hier (Wie Günther schon sagt) meist an generelleren Exceptions orientieren würde - vereinfacht auch die Wiederverwendung in anderen Projekten.

[Stevie]

Der Vorteil des raisen von Exceptions in einer entsprechenden Routine (außer, dass man seinen Code wiederverwertbar kapselt) und nicht direkt im Code, der sie verursacht wurde von Eric Grange schonmal schön erklärt.

Zitat von JasonDX:

Ich finde hier die Idee der Preconditions aus Guava recht praktisch. Diese orientieren sich aber primär an den Exceptions, die sie werfen (InvalidArgumentException, NullPointerException, IllegalStateException, etc.). Der Kontext der Prüfung kann dann in die Message der Exception verpackt werden.

Etwas Delphi-ähnliches ließe sich auch recht leicht realisieren, wobei ich mich hier (Wie Günther schon sagt) meist an generelleren Exceptions orientieren würde - vereinfacht auch die Wiederverwendung in anderen Projekten.

Gibt's schon in ähnlicher Form, nennt sich Spring.Guard .

Obiger Code sähe damit so aus:

Guard.CheckRangeInclusive(aIndex, MinValue, MinValue);