Best Practice: Wann verwendet ihr Exceptions in Funktionen?

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

[Zacherl]

Zitat von Der schöne Günther:

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.

Genau das mache ich bisweilen auch sehr häufig. Dann hat man allerdings wieder mein anfängliches Problem, dass man nicht genau weiß, welcher der API Aufrufe fehlgeschlagen ist. Ist zwar bei lokalem Debugging nicht so wild, weil man einfach mal schnell durch die Funktion steppen kann, aber wenn das Problem nur bei einem Kunden / Anwender auftritt, hat man ein Problem.

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

[Furtbichler]

Zitat von hathor:

Die PROCEDURE READNODE kann nicht funktionieren,
weil das Object XmlDoc nicht bekannt ist.

Na ja, die Prozedur könnte eine lokale Prozedur sein, oder XmlDoc ist ein Feld einer Klasse oder eine globale Variable oder es war einfach nur Pseudocode und sollte nur den Sinn von Refactoring und DRY demonstrieren. In jedem Fall hast Du natürlich recht, sie kann nicht funktionieren: Ich habe sie nämlich noch gar nicht gespeichert

Zitat:

Dieser sinnlose VERBESSERUNGSTRIEB

Wenn das für dich sinnlos ist, dann weiß ich auch nicht. Aber jeder soll so programmieren, wie er es für richtig hält. Das Lustige an DRY ist übrigens, das Du die Prozedur 'ReadNode' ohne Probleme anpassen kannst (z.B. den Fehler loggen), und zwar an dieser einen Stelle. Alle Aufrufe werden sich automatisch und logischerweise dann genau gleich verhalten. Bei deiner Copy&Paste-Vorgehensweise müsstest Du dann an allen Stellen das gleiche machen und wehe Du vertippst dich oder vergisst eine Stelle.

Denk mal drüber nach. Und wenn Du schon dabei bist (am Nachdenken), überlege Dir auch noch, ob dich überhaupt jemand kritisiert hat und wieso Du hier so ausrastest. Ich wollte Dir jedenfalls nicht an den Karren pissen.

Zitat von Der schöne Günther:

...dass ich die Methode eher PrintNode

oder 'ProcessNode' oder so.

Das Handle-Beispiel könnte man auch so lösen, das die 'GetHandleFromElsewhere'-Methode die Exception-Behandlung übernimmt. Oder man macht soetwas:

LHandle1 := CheckHandle (GetHandleFromElseWhere, 'From ElseWhere');
LHandle2 := CheckHandle (GetHandleFromElseWhere (LHandle1), 'From ElseWhere 1');
LHandle3 := CheckHandle (GetHandleFromElseWhere (LHandle2), 'From ElseWhere 2');
LHandle4 := CheckHandle (GetHandleFromElseWhere (LHandle3), 'From ElseWhere 3');

...
Wobei das CheckHandle eine Funktion ist:

Delphi-Quellcode:

Function CheckHandle (aHandle : THandle; Msg : String) : THandle;
Begin
  if aHandle = InvalidHandle then Raise Exception.Create(Msg);
  result := aHandle;
End;

Macht Delphi z.T. ja auch so.

Ich persönlich finde das aber nicht sooo lesbar. Es ist zu empfehlen, wenn man die GetXXXX-Funktionen nicht ändern kann.

Man kann die aber Kapseln, sodaß die Exception-Behandlung im Wrapper stattfindet. Solch ein Code (3-Zeiler) kann ruhig komisch aussehen, da schaut man kurz rein, sagt:'Ach so' und macht das Zeugs wieder zu. Die Wrapper sind dann aber sehr gut zu lesen:

Delphi-Quellcode:

Try
  LHandle1 := GetHandle;
  LHandle2 := GetHandle(LHandle1);
  LHandle3 := GetHandle(LHandle2);
  LHandle4 := GetHandle(LHandle3);
  DoSomething(LHandle1,LHandle2,LHandle3,LHandle4);
Except
  On E:EInvalidHandle Do begin 
    LogError(E);
    Raise EMoreAbstractException.Create(E); 
  End;
End;

Und das ist dann schon wieder schön knackig.
Die 'EMoreAbstractException' analysiert die innere Exception (kann ja unterschiedliche Gründe haben) und erzeugt eine Exception, die die Details verschweigt. Der Aufrufer interessiert sich ja nicht dafür, das der USB-Treiber aufgrund ungültiger Installationsparameter im 3.Duktus links kein Handle bereitstellen kann. Wichtig ist: 'Es funzt net'. Details stehen im Log.

@JasonDX: Wenn da wirklich nur ein Return erfolgen soll, ist das grenzwertig. Meist ist so ein stillschweigendes Scheitern schlechter Stil. WENN es aber genaus so sein soll, ist das mit dem Return schon so richtig.

Da ginge aber auch (besser?) sowas:

Delphi-Quellcode:

if not TryGetHandle (LHandle1) then return;
if not TryGetHandle (LHandle1,LHandle2) then return;
if not TryGetHandle (LHandle2,LHandle3) then return;
if not TryGetHandle (LHandle3,LHandle4) then return;

Wieder knackig kompakt

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