Best Practice: Wann verwendet ihr Exceptions in Funktionen?

[Zacherl]

Hallo zusammen,

gibt es ein Bestimmtes Schema, an das ihr euch haltet, wenn es um die Verwendung von Exceptions in Funktionen geht? Ich bin mir nie sicher, wann es sinnvoller ist eine Exception zu schmeißen, statt einen boolschen Rückgabewert zu verwenden.

Beispiel:
Eine Funktion, die viele subsequente API Aufrufe macht. Bei Exceptions könnte ich den Namen der API und den Error Code zurückgeben. Wenn ich mit einem boolschen Rückgabewert arbeite, kann ich nur signalisieren dass EINER der API Aufrufe fehlgeschlagen ist und den Error Code außerhalb mit GetLastError erfragen.

Zu wissen welche API fehlgeschlagen ist, kann sehr nützlich sein, wenn auf dem eigenen System alles funktioniert, aber ein Kunde / Anwender nicht nachvollziehbare Probleme hat.

Viele Grüße
Zacherl

[Aphton]

Daran wäre ich auch interessiert.

Mir scheints so, als ob Exceptions eigentlich genau für diesen Zweck geschaffen worden sind (Sprachkonstrukt) - daher sollte man, wenn man sauber programmieren will, diese verwenden!

Ich habe aber keine berufspraktische Erfahrungen und kann nicht wirklich sagen, was sich bewährt.

[hathor]

Wenn ich z.B. ein XML-File auslese in verschiedenen WINDOWS-Versionen,
muss ich damit rechnen, dass nicht alle Werte vorhanden sind.

Delphi-Quellcode:

...
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/SystemScore');
    Form1.Memo1.lines.add(Format(' 1. SystemScore       %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/MemoryScore');
    Form1.Memo1.lines.add(Format(' 2. MemoryScore       %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/CpuScore');
    Form1.Memo1.lines.add(Format(' 3. CpuScore          %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/VideoEncodeScore');
    Form1.Memo1.lines.add(Format(' 4. VideoEncodeScore  %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/GraphicsScore');
    Form1.Memo1.lines.add(Format(' 5. GraphicsScore     %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/GamingScore');
    Form1.Memo1.lines.add(Format(' 6. GamingScore       %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;
try
    Nodes := XmlDoc.selectNodes('//WinSAT/WinSPR/DiskScore');
    Form1.Memo1.lines.add(Format(' 7. DiskScore         %s',[Nodes.Item(0).Text]));
except on E:Exception do Form1.Memo1.lines.add('  ---> Score not exists.'); end;

[Phoenix]

Exceptions sind genau das, was sie Aussagen: Ausnahmen.

Man sollte eine Exception nur genau dann werfen, wenn das Modul das gerade Arbeitet wirklich in eine Situation kommt, die es nicht mehr korrekt Abarbeiten kann. Im Falle einer tatsächlich möglichen und erwarteten Fehlersituation sollte keine Exception geworfen werden.

Was man unbedingt vermeiden sollte ist, Exceptions zum Kontrollfluss zu verwenden. Das führt sehr schnell zu Spaghetticode und damit zu schlecht wartbaren Systemen.

Hathor hat da natürlich auch gerade eine Paradebeispiel für dieses Anti-Pattern geliefert. Wenn ich schon davon ausgehen muss, das bestimmte Knoten nicht vorhanden sind, dann kann ich deren Existenz vorher abprüfen und entsprechend sauber mit if/else Statements darauf reagieren. Das ist keine Ausnahme, sondern ein möglicher und je nach WIndows-Version vollkommen normaler Zustand.

Wenn allerdings der Root-Knoten in meinem XML der falsche ist, dann wäre das eine Ausnahme (z.B. falsches File gelagen?) mit der ich in meinem Code nicht umgehen kann. Hier kann ich dann Problemlos eine Exception werfen.

Edit Nachtrag:
Noch was zum Thema warum Exceptions nur selten genutzt werden sollten.
1.) Sind Exceptions im Code äquivalent zu nicht-lokalen und optionalen GOTO's. Sie brechen den Programmfluss an einer Stelle hart ab, und der nächste Einsprungspunkt liegt (oder auch nicht) in komplett anderem (nämlich ggf. irgend einem X Ebenen höher aufrufenden) Codeblock. Das macht die ganze Sache zu Spaghetti- und unwartbaren Code.
2.) Gehen die Designer des Compilers und der Runtime auch davon aus, das Exceptions seltene Ausnahmefälle darstellen. Dementsprechend ist der Code für das Exception-Handling üblicherweise (da nur selten verwendet) nicht hochoptimiert. Das Werfen einer Exception ist in Sachen Performance in aller Regel eine sehr teure Operation.

[himitsu]

Wenn nahezu immer mit einem Fehler zu rechnen ist und/oder wenn der Fehler "egal" ist, dann ein Boolean.
Auch wenn man den Fehler "schnell" z.B. via IF mit einer alternativen Variante behenben kann.

Zusätzlich kann man SetLastError oder eine Variable nutzen, um "erweiterte" Informationen weiterzugeben. (globale Variable, Property usw.)

-

Wenn unterschiedliche Fehler auftreten können und man daruaf reagieren können soll, dann z.B. HRESULT, Integer oder ein Enum, für erweiterte Informationen.

-

Wenn es ein "schwerwiegender" Fehler ist, bei dem die hauptsächliche Funktion nicht gewährleistet ist
und/oder wenn "selten" Fehler auftreten
oder wenn die "ausführliche" Fehlerinformation nicht ordentlich als Result zurückgegeben werden können *1,
dann Exceptions.

*) z.B. wenn es schon ein Result gibt und man in Diesem auf keine "ungültigen" Werte als Fehlerinformationen nutzen kann (z.B. siehe ShellExecute)

-

z.B. IntToStr muß eine Exception werfen, aber TryIntToStr gibt nur den Boolean zurück und Val einen "Fehlercode", bzw. die Fehlerposition.

[nahpets]

Hallo,

meine persönlich Ansicht zu dem Thema (man kann sie teilen, muss es aber nicht):

Exceptions benutze ich grundsätzlich nicht als Rückgabewert. Nie!!!

Eine Exception weist mich immer auf einen Fehler hin, bei dem ich "zu blöd" war, ihn durch eine vernünftige Programmierung abzufangen.
Eine Exception ist immer eine Ausnahmesituation, in der versucht wird zu retten, was noch zu retten ist.
Sie dient niemals zur Steuerung irgendwelcher Programmabläufe.

Kann mich an ein Programm erinnern, dass ich von einem anderen Entwickler übernehmen musste. Er steuerte den Programmablauf durch Exceptions. Bei ihm gab es sowas wie EGoodException und EBadException (die hießen wirklich so und waren von EException abgeleitet). Und dann gab es noch etliche "Zwischendinger", die für mehr oder weniger gute oder schlechte Situationen genutzt wurden. Für mich persönlich läuft das unter "sehr schlechtem Programmierstil".

In dem besagten Programm war es extrem schwierig herauszubekommen, in welchem Programmteil es nach den diversen Exceptions nun weiterging bzw. was zur Fehlerbehandlung diente.

Es erinnert mich an andere Programme, die ich mal mitpflegen durfte (Basic bzw. PL/1). Dort wurde der Programmablauf nie in der Form

Delphi-Quellcode:

if x = y then begin
...
end;

gesteuert, sondern immer in der Form

Delphi-Quellcode:

if not (x = y) then GoTo Pxyz;
...
Hier dann die Logik für die Bedingung x = y
...
Goto Pxyz;

wobei xyz eine nummerischer Wert von 000 bis 999 sein konnte.

Extrem schwer, sich dort einzulesen und zurechtzufinden.
Funktionen oder Prozeduren wurden dort nicht genutzt, in Basic eventuell mal ein GoSub, aus dem aber durchaus per GoTo irgendwo in den Quelltext zurückgesprungen wurde, aus dem das GoSub aufgerufen wurde oder per GoTo irgendwo in so ein Sub mitten "hineinaberneineberneinabernein" und dann irgendwie mit GoTo wieder raus, da der "normal" Rückweg hinaus ja dann nicht funktioniert.

Mit dieser Methode und "Steuerung per Exception" kann man wunderbaren Spagetticode erstellen, dessen Unpflegbarkeit quasi mit der Erstellung schon sichergestellt ist.
Für meine Begriffe ist dieses Vorgehen hochgradig unprofessionell. Habe bisher keine Software kennengelernt, die dauerhaft mit derartigen Konstrukten wartbar und weitereinwickelbar war.

Exception bedeutet meines Wissens Ausnahme und nicht Regel.

Exceptions dienen zur Ausnahmebehandlung (in der Regel ist dies die Fehlerbehandlung) und nicht zur regulären Programmsteuerung.

http://de.wikipedia.org/wiki/Ausnahmebehandlung

Was hathor beschreibt ist keine "Funktionssteuerung" per Exception statt Rückgabewert, sondern eine Fehlerbehandlung. Im Fehlerfalle wird eine alternative Ausgabe gemacht. Die Funktion selbst behandelt die Fehler (hier fehlende Inhalte). Bei einer Fehlerbehandlung "per Exception" müsste hier für jeden der möglichen Fehler eine spezielle Exception existieren und natürlich auch für jede der daraus möglichen Kombinationen, da diese Funktion ja offensichtlich bei allen Fehlern schon selbst etwas macht bzw. die Fehler bei einer Exceptionsteuerung sammeln müsste, um sie dann gemeinsam weiterzugeben. Jeder einzelne Fehler kann ja nicht mit einer eigenen Exception zurückgegeben werden, ohne den Programmablauf nach dem ersten Fehler zu unterbrechen. In dem Falle wäre eine Exceptionsteuerung mit einem nicht unerheblichen Programmieraufwand und einem nicht unerheblichen "Unübersichtlichkeitsfaktor" verbunden. Viel Vergnügen beim Implementieren.

Funktionen können bei korrekter Verarbeitung z. B. True und im Fehlerfalle False zurückgeben. Der Rest kann durchaus per VAR-Parameter zurückgegeben werden. Als Rückgabewert und/oder VAR-Parameter sind aber durchaus auch Records oder Klassen mit entsprechenden Attributen möglich. Hier geht (bei durchdachter Planung) deutlich mehr als ein "geht" oder "gehtnicht" (True / False).

Phoenix hat mit seiner Aussage absolut recht.

[OlafSt]

Ab und zu ist es mal interessant, den generierten Assemblercode seines Programms zu betrachten. Wenn man dann sieht, was der Compiler an Massen von Code produziert, um so einen try..except-Block "abzuwickeln", wird einem echt übel und es wundert einen nicht mehr, das das Programm so elend vor sich hin schneckt.

Da beginnt man dann rasch wieder damit, Exceptions für seinen eigentlichen Zweck zu benutzen: Das Abfangen unvorhergesehener Probleme, damit das programm dann stabil bleibt. Zur Flusssteuerung sind Exceptions mehr als nur ungeeignet.

[Furtbichler]

Zitat von Phoenix:

Hathor hat da natürlich auch gerade eine Paradebeispiel für dieses Anti-Pattern geliefert.

Schnippeldi-Refaktor-DRY:

Delphi-Quellcode:

Procedure ReadNode (string title, nodeKey);
Begin
  try
      Nodes := XmlDoc.selectNodes(nodeKey);
      Form1.Memo1.lines.add(Format('%20s %s',[title,Nodes.Item(0).Text]));
  except  
    on E:Exception do 
      Form1.Memo1.lines.add(string,Format('---> %s not exists.',[title]); 
  end;
End;
...
  ReadNode('1. SystemScore'     ,'//WinSAT/WinSPR/SystemScore');
  ReadNode('2. MemoryScore'     ,'//WinSAT/WinSPR/MemoryScore');
  ReadNode('3. CpuScore'        ,'//WinSAT/WinSPR/CpuScore');
  ReadNode('4. VideoEncodeScore','//WinSAT/WinSPR/VideoEncodeScore');
  ReadNode('5. GraphicsScore'   ,'//WinSAT/WinSPR/CpuScore'); 
  ReadNode('6. GamingScore'     ,'//WinSAT/WinSPR/GamingScore'); 
 ...

Ich kann mir nicht helfen: Eher ein Paradebeispiel, wie lesbar Code mit Exceptions wird (Und das ist noch nicht einmal gut refaktorisiert)

[Zacherl]

Zum Kontrollfluss missbrauche ich meine Exceptions auf jeden Fall nicht. Ich denke eher, dass ich in manchen Situationen zu wenig Exceptions verwende. Nehmen wir mal als konkretes Beispiel mal eine simple DLL Injection, welche aus einer Abfolge der APIs

1. OpenProcess
2. VirtualAllocEx
3. WriteProcessMemory
4. CreateRemoteThread

besteht. Hier ist es so, dass die komplette Funktion fehlschlägt, wenn auch nur eine einzige dieser API Aufrufe nicht erfolgreich ist. Demnach würde hier jeweils die Situation eintreten, dass meine Funktion nicht mehr korrekt Arbeiten kann.

Ich habe nun zwei Möglichkeiten:

1. Nach jedem API Aufruf die Rückgabe prüfen und bei Fehlschlag eine Exception in der Funktion schmeißen
2. Bei einem fehlerhaften API Aufruf die komplette Funktion abbrechen, FALSE zurückgeben, außerhalb der Funktion die Rückgabe prüfen und dann eine Exception schmeißen

Die Exception schmeißen müsste ich also so oder so, nur ist die Frage, ob dies an zentraler Stelle (außerhalb der Funktion) oder dezentral (evtl. mit genaueren Informationen) innerhalb der Funktion geschieht.

@himitsu:
Ein HRESULT als Rückgabe wäre natürlich eine Alternative zum Boolean, aber hier habe ich die Befürchtung, dass der Code recht schnell unübersichtlich werden könnte. Zumindest müsste ich mir bezogen auf mein obiges Beispiel dann verschiedene Konstanten für ERROR_API1_FAILED, ERROR_API2_FAILED, ... anlegen.

@nahpets:
Ein Record als Rückgabeparameter erscheint mir jetzt spontan als "ungewöhnlicher Stil", aber ist vermutlich gar keine schlechte Idee. Hier könnte ich neben einem Indikator für FAIL oder SUCCESS zusätzlich noch den Namen der fehlgeschlagenen API zurückgeben.

[JasonDX]

Ich werfe immer dann Exceptions, wenn ein Fall auftritt der ein Verhalten erfordert, das nicht von der Methode selbst kontrolliert werden soll. Andernfalls handhabt die Methode den Fehler entsprechend. Hilfreich ist in solchen Fällen auch, filterbare Log-Ausgaben zu generieren.
Durch Fehlercodes über Rückgabewerte zu kommunizieren finde ich befremdlich. Man kann nur wenig Informationen über den Fehler mitgeben, und es passiert allzuleicht, Fehler zu ignorieren (Viel Spaß beim Debuggen). Deswegen sollte diese Variante weitmöglichst vermieden werden.

Zitat von Phoenix:

Noch was zum Thema warum Exceptions nur selten genutzt werden sollten.
1.) Sind Exceptions im Code äquivalent zu nicht-lokalen und optionalen GOTO's. Sie brechen den Programmfluss an einer Stelle hart ab, und der nächste Einsprungspunkt liegt (oder auch nicht) in komplett anderem (nämlich ggf. irgend einem X Ebenen höher aufrufenden) Codeblock. Das macht die ganze Sache zu Spaghetti- und unwartbaren Code.

Es hängt stark von "selten nutzen" ab - aber im Endeffekt sind Exceptions keineswegs GoTos, und haben einen sehr linearen Verlauf. Wenn ein Fehler auftritt, den man in der Methode selbst nicht behandeln kann hat man mehrere Möglichkeiten:
1. man ignoriert den Fehler (ouch)
2. man meldet dem Aufrufer über Rückgabewert oder Parameter, dass ein Fehler aufgetreten ist
3. man schmeißt eine Exception
Excepions sind da die Wahl der Qual. Zudem bieten sie weitaus saubereren Code und können viel Informationen über den Fehler mitgeben, um die bestmögliche Fehlerbehandlung zu erlauben.

Zitat von Phoenix:

2.) Gehen die Designer des Compilers und der Runtime auch davon aus, das Exceptions seltene Ausnahmefälle darstellen. Dementsprechend ist der Code für das Exception-Handling üblicherweise (da nur selten verwendet) nicht hochoptimiert. Das Werfen einer Exception ist in Sachen Performance in aller Regel eine sehr teure Operation.

Richtig. Normalerweise wird auch in Performance-intensiven Anwendungen erst die Eingaben auf Fehler geprüft, dann der aufwendige Task gestartet.