Best Practice: Wann verwendet ihr Exceptions in Funktionen?

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

[himitsu]

Was man auch nicht vergessen darf:
Exception im Programmablauf machen das Debuggen nicht grade leichter,
also bezüglich "damit den Programmfluß zu steuern".

Delphi-Quellcode:

try
  i := StrToInt(S);
except
  i := 0;
end;

Jetzt debuggt mal einen Code, wo sowas alle 2 Sekunden durchlaufen wird und öfters keine Zahl im S drin steckt.

[Sir Rufo]

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Beispiel ohne Exceptions:

Delphi-Quellcode:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 <> INVALID_HANDLE then
  begin
    LHandle2 := GetHandleFromElsewhere( LHandle1 );
    if LHandle2 <> INVALID_HANDLE then
    begin
      LHandle3 := GetHandleFromElsewhere( LHandle2 );
      if LHandle3 <> INVALID_HANDLE then
      begin
        LHandle4 := GetHandleFromElsewhere( LHandle3 );
        if LHandle4 <> INVALID_HANDLE then
        begin
          DoSomethingWithHandles( LHandle1, LHandle2, LHandle3, LHandle4 );
        end;
      end;
    end;
  end;
end;

Jetzt mal mit Exceptions

Delphi-Quellcode:

type 
  EInvalidHandleException = class( Exception );

procedure CheckInvalidHandle( AHandle : THandle; const AText : string );
begin
  if AHandle = INVALID_HANDLE then
    raise EInvalidHandleException.Create( AText );
end;

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElseWhere;
  CheckInvalidHandle( LHandle1, 'from ElseWhere' );

  LHandle2 := GetHandleFromElseWhere( LHandle1 );
  CheckInvalidHandle( LHandle2, 'from ElseWhere' );

  LHandle3 := GetHandleFromElseWhere( LHandle2 );
  CheckInvalidHandle( LHandle3, 'from ElseWhere' );

  LHandle4 := GetHandleFromElseWhere( LHandle3 );
  CheckInvalidHandle( LHandle4, 'from ElseWhere' );

  DoSomethingWithHandles( LHandle1, LHandle2, LHandle3, LHandle4 );
end;

[himitsu]

Zitat von Sir Rufo:

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Ja, das schon, aber nur solange recht "selten" mal ein Handle nicht geliefert werden konnte.

Wobei du aber auch die Funktionsweise von foo geändert hast.
Beim ersten foo, mit den IFs, bekommt keiner mit, ob DoSomethingWithHandles verarbeitet wurde.

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

[Der schöne Günther]

Der Beitrag doch sogar eigentlich vollkommen zu deinen Gunsten? Hier muss doch niemand etwas beweisen und außerdem haben wir uns alle gern

[Meflin]

Zitat von Sir Rufo:

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Beispiel ohne Exceptions:
... Jetzt mal mit Exceptions
...

Na sorry aber das ist ja jetzt Äpfel mit Birnen verglichen. Das Beispiel ohne Exceptions kann man genauso leserlich und ohne verschachtelte ifs aufschreiben und trotzdem keine Exceptions verwenden... indem man einfach Guard Clauses benutzt. Soll heißen:

Code:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 = INVALID_HANDLE then return;
  
  LHandle2 := GetHandleFromElsewhere(LHandle1);
  if LHandle2 = INVALID_HANDLE then return;
  ...
end;

Persönlich bin ich nicht von der Notwendigkeit von Exceptions überzeugt. Vor allem finde ich, dass die Exceptionbehandlung in den meisten Sprachen (auch in Delphi) nicht wirklich schön lesbarer Code ist.

[JasonDX]

Zitat von Meflin:

Code:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 = INVALID_HANDLE then return;
  
  LHandle2 := GetHandleFromElsewhere(LHandle1);
  if LHandle2 = INVALID_HANDLE then return;
  ...
end;

Persönlich bin ich nicht von der Notwendigkeit von Exceptions überzeugt. Vor allem finde ich, dass die Exceptionbehandlung in den meisten Sprachen (auch in Delphi) nicht wirklich schön lesbarer Code ist.

In diesem Beispiel sind Exceptions tatsächlich nicht notwendig, denn der Fall der geprüft wird, wird nicht direkt als Fehlerfall gehandhabt wird. Aber: Nehmen wir an, die Methode hat als Voraussetzung, dass alle 4 Handles gegeben sind. Wie sieht dann die If-Abfrage aus, bzw. wie wird dem Aufrufer am besten mitgeteilt, dass die Daten, die übergeben wurden, nicht valide waren?

Für den Fall, dass eine Methode einen Fehlerfall nicht korrekt behandeln kann, sind Exceptions ein valider, sauberer und sinnvoller Weg.