try ... except --> wann verwenden ???

[smudo]

Ich vermisse unter Delphi einen Try-Except-Finally-End Block. Dann wären Speicherlecks recht komfortabel auszuschließen. C# hat sowas.

[alzaimar]

Ich finde, man sollte Try ... Except Blöcke dann verwenden, wenn im Normalfall nichts passiert, aber eine Ausnahme (nichts anderes bedeutet ja 'Exception') gesondert behandelt werden sollte.

Zitat von Matze:

ich würde es da nutzen, wo Fehleingaben vom Benutzer Fehler verursachen würden bzw. allgemein da, wo Fehler leicht auftreten können. Wenn möglich solltest du jedoch try-except weitmöglich umgehen und lieber per if-Abfragen prüfen, ob etwas funktioniert hat oder nicht, finde ich. Das ist je nach Situation natürlich unterschiedlich.

Grausam, dabei kommt sehr unübersichtlicher Code heraus:

Delphi-Quellcode:

If ActionA=aSuccess Then
  If ActionB = Success Then
    If ActionC = Success Then
      If ActionD = Success Then
         .....
      else
        ....
   else
 ...

Oder auch

Delphi-Quellcode:

aResult := ActionA;
If aResult<>Success Then Exit;
aResult := ActionB;
If aResult<>Success Then Exit;
aResult := ActionC;
If aResult<>Success Then Exit;
aResult := ActionD;
If aResult<>Success Then Exit;

vs.

Delphi-Quellcode:

Try
  ActionA;
  ActionB;
  ActionC;
  ActionD;
Except
  Raise Exception.Create('Bei der Abarbeitung der Aktionen ist ein Fehler aufgetreten');
End;

Also, schreib mal übersichtlicheren und robusten Code ohne Try...Except.

Es ist natürlich beim Design und Debuggen etwas nervig, wenn einem Exceptions um die Ohren fliegen. Aber erstens kann man das ausschalten und zweitens ist es ja eine Ausnahme, die eben nur in Ausnahmefällen vorkommen sollte.

Programmfehler würde ich mit Assert-Anweisungen vermeiden, Logische Prüfungen von Eingaben vermutlich über einen Parser / DEA analysieren und bei einem Fehler eine Exception 'EUserInputException' schmeissen, die die genaue Ursache und Position beinhaltet.

Zum Beispiel vom Dezipaitor. Variante A (Wenn der Fehler weitergereicht werden soll);

Delphi-Quellcode:

MyOBject:= TMyObject.Create;
Try
  Try
    MyObject.CriticalMethod;
  Except
    On E:ESomeException Do Begin
      HandleSomeException (E);
      Raise
    End
  End
Finally
  MyObject.Free;
End;

Und wenn nicht:

Delphi-Quellcode:

MyObject:= TMyObject.Create;
Try
  MyObject.CriticalMethod;
Except
  On E:ESomeException Do 
    HandleSomeException (E);
End;
MyObject.Free;

Letzteres ist die sog. 'Halts Maul' Variante, die man durch einen überflüssigen Try..Finally Block kapseln kann:

Delphi-Quellcode:

MyObject:= TMyObject.Create;
Try
  Try
    MyObject.CriticalMethod;
  Except
    On E:ESomeException Do 
      HandleSomeException (E);
  End;
Finally
  MyObject.Free;
End;

[smudo]

Beim Befüllen einer Caption halte ich es nicht sinnvoll (was soll dabei schief gehen und was soll ich anschließend mit der abgefangenen Exception machen)
Ich setze es immer nur dann ein, wenn ich nach einer schiefgelaufenen Aktion etwas unternehmen muss. Z.B. ein Rollback

Delphi-Quellcode:

StartTransaction
try
 ...
except
  RollBack;
  raise;
end;
Commit;

[alzaimar]

[Klugscheiss]Da jedoch das Commit konzeptionell zur Aktion gehört, sollte man es auch in den Block packen [/Klugscheiss]

Delphi-Quellcode:

StartTransaction
try
...
  Commit;
except
  RollBack;
  raise;
end;

Es tut aber eigentlich Nichts zur Sache.

[dajuhsa]

Zitat von smudo:

Ich vermisse unter Delphi einen Try-Except-Finally-End Block. Dann wären Speicherlecks recht komfortabel auszuschließen. C# hat sowas.

wie wärs mit

Delphi-Quellcode:

try
  ...
  try
    ...
  except
    ...
  end;
finally
  ...
end;

[Matze]

Zitat von alzaimar:

Grausam, dabei kommt sehr unübersichtlicher Code heraus [...]

Zitat von Matze:

Das ist je nach Situation natürlich unterschiedlich.

Ich ging nun von Fehleingaben aus, die Christian angesprochen hat. Da würde ich persönlich beispielsweise eher TryStrToInt nutzen als einen try-except-Block. Aber das bleibt jedem selbst überlassen.
Bei komplexeren Strukturen, wie du sie ansprichst, ist das natürlich nicht sonderlich sinnvoll, auf try-except zu verzichten.

[squetk]

Zitat von alzaimar:

[Klugscheiss]Da jedoch das Commit konzeptionell zur Aktion gehört, sollte man es auch in den Block packen [/Klugscheiss]

Delphi-Quellcode:

StartTransaction
try
...
  Commit;
except
  RollBack;
  raise;
end;

Sehe ich nicht so, weil zwischen try und except doch Anweisungen stehen müssten, die im Fehlerfalle ein Rollback auslösen sollen. Das kann ich mir beim Commit als "Gegenstück" zum Rollback nicht vorstellen. Sollte beim Commit wider Erwarten eine Exception auftreten, wäre ein Rollback auch sinnlos.

[Christian Seehase]

Moin squetk,

Zitat von squetk:

Sollte beim Commit wider Erwarten eine Exception auftreten, wäre ein Rollback auch sinnlos.

Das ist zwar richtig, aber der try/except-Block kapselt ja den Normalfall, der dann mit Commit abgeschlossen würde, womit Commit logisch in den Block gehört.

[alzaimar]

Weiterhin muss - bei korrekter ACID-Implementierung - das Rollback auch ein fehlerhaftes Commit rückgängig machen können.

Zitat von Matze:

Ich ging nun von Fehleingaben aus, die Christian angesprochen hat. Da würde ich persönlich beispielsweise eher TryStrToInt

Nach nochmaligem Lesen interpretiere ich Deine Äußerungen auch so. Mea Culpa.

[smudo]

Das fänd ich jetzt mal interessant.
Was kann dazu führen, dass ein Commit fehlschlägt - was ein Rollback reparieren könnte?
Und was ist ACID? Ich kenn nur die Musikrichtung