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.

[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)

[Der schöne Günther]

Zitat von Furtbichler:

Schnippeldi-Refaktor-DRY:

Abgesehen davon, dass ich die Methode eher PrintNode genannt hätte: Entsprechend dokumentiert ist die Methode doch super: Die Methode ist kurz, knackig, übersichtlich und verhält sich für den Benutzer absolut vorhersehbar.


Wobei ich im "Vier Handles"-Beispiel jetzt grübele, warum man nicht einfach die Funktion um einen "Erfolgreich?"-Rückgabe-Boolean erweitert und statt einer Exception einfach mit Exit(False) rausspringt. Finde ich ok und tue es oft ohne mich zu schämen.

[hathor]

Zitat von 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)

Die PROCEDURE READNODE kann nicht funktionieren,
weil das Object XmlDoc nicht bekannt ist.
Es ständig neu zu erzeugen und zu verwerfen macht auch keinen Sinn.

Dieser sinnlose VERBESSERUNGSTRIEB mancher "Zeitvertreiber" ist auch der Grund, warum ich hier meine Projekte nicht veröffentliche!

[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.

[jaenicke]

Zitat von Zacherl:

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.

Und genau an der Stelle sind Exceptions genau richtig. Es handelt sich um eine Ausnahme vom regulären Programmablauf und du kannst an der Stelle nicht weitermachen und auch der Aufrufer kann an der Stelle nicht ohne Fehlerbehandlung weitermachen. Damit das korrekt behandelt werden kann, lieferst du mit der Exception die nötigen Informationen. Genau dafür sind Exceptions da.

Das hat an der Stelle auch nichts mit Programmsteuerung zu tun. Dafür sind sie, zumindest in den allermeisten Fällen in der Tat ungeeignet.