Kleiner Exkurs zu Exceptions (try finally/except)

[MaBuSE]

In meinem Lieblingsthread "Eure besten Quellcode Kommentare..." wurde folgender Quellcode Kommentar gesendet.

Zitat von Neutral General:

Delphi-Quellcode:

{$IFDEF MSWINDOWS}
procedure DLLShutdown; stdcall;
begin
  try
    if @DLLShutdownProc <> nil then
      DLLShutdownProc;
  finally
    // eat all exception.
  end;
end;
{$ENDIF MSWINDOWS}

Zitat von Neutral General:

Die DLLShutdown-Methode die ich gepostet habe ist übrigens aus der System.pas. (10.3.2)
Genau so geschrieben und kommentiert.

Da es wohl auch bei Borland /Embarcadero / Idera Leute gibt, die sich noch nicht richtig mit dem Thema befasst haben, habe ich hier mal eine kleine Zusammenfassung geschrieben.


try ... finally ... end; Block

Delphi-Quellcode:

...
  WriteLn('Null - ohne Exception');
  try
    WriteLn('Eins');
    WriteLn('Zwei');
    WriteLn('Drei');
  finally
    WriteLn('Vier');
  end; // hier wird die Exception nochmal geworfen (analog raise)
  WriteLn('Fünf');
...
  WriteLn('Null - mit Exception');
  try
    WriteLn('Eins');
    WriteLn(StrToInt('Zwei'));
    WriteLn('Drei');
  finally
    WriteLn('Vier');
  end; // hier wird die Exception nochmal geworfen (analog raise)
  WriteLn('Fünf');
...

Gibt Ausgabe:

Code:

...
Null - ohne Exception
Eins
Zwei
Drei
Vier
Fünf
Null - mit Exception
Eins
Vier
Exception

Vier wird auf jeden Fall ausgeführt. Egal ob eine Exception auftritt oder nicht.

try ... except ... end; Block

Delphi-Quellcode:

...
  WriteLn('Null - Ohne Exception');
  try
    WriteLn('Eins');
    WriteLn('Zwei');
    WriteLn('Drei');
  except
    WriteLn('Vier');
  end;
  WriteLn('Fünf');
...
  WriteLn('Null - mit Exception');
  try
    WriteLn('Eins');
    WriteLn(StrToInt('Zwei'));
    WriteLn('Drei');
  except
    WriteLn('Vier');
  end;
  WriteLn('Fünf');
...

Gibt Ausgabe:

Code:

...
Null - Ohne Exception
Eins
Zwei
Drei
Fünf
Null - mit Exception
Eins
Vier
Fünf

Vier wird nur ausgeführt, wenn eine Exception auftritt.


Verschachtelungen:
finally-except

Delphi-Quellcode:

...
  WriteLn('Null');
  try
    try
      WriteLn('Eins');
      WriteLn(StrToInt('Zwei'));
      WriteLn('Drei');
    finally 
      WriteLn('Vier');
    end; // hier wird die Exception nochmal geworfen (analog raise)
  except
    WriteLn('Fünf');
  end;
  WriteLn('Sechs');
...

Gibt Ausgabe:

Code:

...
Null
Eins
Vier
Fünf
Sechs
...

except-finally

Delphi-Quellcode:

...
  WriteLn('Null');
  try
    WriteLn('Eins');
    try
    WriteLn(StrToInt('Zwei'));
    except
      WriteLn('Drei');
    end; // Exception abgefangen
    WriteLn('Vier');
  finally 
    WriteLn('Fünf');
  end; // hier wird die Exception nochmal geworfen (analog raise), falls eine aufgetreten ist und nicht abgefangen wurde.
  WriteLn('Sechs');
...

Gibt Ausgabe:

Code:

...
Null
Eins
Drei
Vier
Fünf
Sechs

Warum das ganze?
try ... finally wird dazu verwendet, sicherzustellen, dass bestimmter Code auch nach einer Exception ausgeführt wird. Z.B. das Freigaben eines Objekts.
Der Code zwischen finally und end wird also auf jeden Fall ausgeführt, egal ob ein Fehler auftritt oder nicht.

Delphi-Quellcode:

...
  MyObject := TMyObject.Create
  try
    MyObject.DoSomething;
  finally
    MyObject.Free;
  end;
...

try except wird dazu verwendet Fehler abzufangen und darauf zu reagieren.
Der Code zwischen except und end wird nur im Fehlerfall ausgeführt

Delphi-Quellcode:

...
  try
    i := StrToInt(s);
  except
    WriteLn('Es ist ein Fehler aufgetreten. s ist kein Integer');
  end;
...
  // oder
  try
    i := StrToInt(s);
  except
    on E: Exception do
    begin
      WriteLn('Es ist ein Fehler aufgetreten.');
      WriteLn('Fehlermeldung: ', E.Message);
    end;
  end;
...

Besser ist es aber bei "erwarteten" Fehlern nur die entsprechende Fehlerklasse abzufangen.
(Anmerkung: Noch besser wäre es natürlich den erwarteten Fehler zu vermeiden, statt per Exception abzufangen.)

Delphi-Quellcode:

...
  try
    i := StrToInt(s);
  except
    on E: EConvertError do
    begin
      WriteLn('Es ist ein Fehler aufgetreten.');
      WriteLn('Fehlermeldung: s ist keine Ganzzahl');
    end;
    on E: EAnderErwarteterFehler do WriteLn('Andere Fehlermeldung');
  end; // Hier wird dann für jeden anderen Fehler außer EConvertError und EErwarteterFehler eine Exception geworfen.
...

Es gibt aber auch ein paar Fallstricker bei verschachtelten Exceptions.
Z.B. werden bei manchen Exceptions die objekte, in denen der Fehler aufgetreten ist referenziert.
Wenn hier in einem finally das objekt freigegeben wird, gibt's beim Zugriff auf die Referenz im Exception Objekt evtl eine allgemeine Schutzverletzung.

Zu dem Thema gibt es noch viel zu Schreiben: globales Exception handling, Unterstützung durch z.B. jcl, MAD-Except, ...

[Gyrospeter]

Vielen Dank, für mich als Programmier-Azubi eine gute Exkursion

[jobo]

Mir ist die Sache durch die Quellcodekommentare aufgefallen.

Deine Beispiel erscheint mir aber etwas seltsam. (Randnotiz, wieso kann man das nicht zitieren?)

Zitat:

...
try
i := IntToStr(s);
except
WriteLn('Es ist ein Fehler aufgetreten. s ist kein Integer);
end;
...

Es würde wohl einen Kompilerfehler ergeben. Das fehlende Anführungszeichen deutet auch darauf hin, dass Du es nur getippt und nicht laufen lassen hast.

So oder so:
Bei
intToStr würde man wohl eher
s := IntToStr(i);

verwenden und das Beispiel würde Sinn ergeben, wenn man wie oben irgendwo die Funktion StrToInt() verwendet, was Du vermutlich eigentlich machen wolltest. Hier können prima Laufzeitfehler auftreten, die als Opfer für Try Except herhalten können:

i := StrToInt(s);

[MaBuSE]

Zitat von jobo:

Mir ist die Sache durch die Quellcodekommentare aufgefallen.
Deine Beispiel erscheint mir aber etwas seltsam. ...
Es würde wohl einen Kompilerfehler ergeben. Das fehlende Anführungszeichen deutet auch darauf hin, dass Du es nur getippt und nicht laufen lassen hast.

Danke
Du hast absolut Recht. Ich hab hier gerade kein Delphi zur Hand.

Ich hab das mal schnell korrigiert

[himitsu]

Die CLI-Vorlage hat IMHO auch schon immer eine kleines Fehlerchen.
Wenn die Anwendung direkt und nicht aus einer Konsole mit Output-Stream gestartet wurde, dann sollte nach dem Except+WriteLn(E.Message) noch ein ReadLn rein, denn sonst kann doch niemand die Exception lesen


Schade ist tzwar, dass man Try/Finally/Except bzw. Try/Except/Finally nicht "direkt" kombinieren kann (also ein Try gefolgt von mehreren Except/Finaly).
Aber naja.

Indirekt geht es, allerdings nur zum Antzeigen der Exception, bzw. zum zusätzlich darauf reagieren.

Zitat:

try
...
finally

E := System.ExceptObject as Exception; // analog zum "on E: Exception" im except, aber das implizite "raise;" bleibt drin
...

end;

[MaBuSE]

Zitat von himitsu:

Die CLI-Vorlage hat IMHO auch schon immer eine kleines Fehlerchen.
Wenn die Anwendung direkt und nicht aus einer Konsole mit Output-Stream gestartet wurde, dann sollte nach dem Except+WriteLn(E.Message) noch ein ReadLn rein, denn sonst kann doch niemand die Exception lesen

Nein

Du kannst auch aus einer GUI Anwendung jederzeit mit AllocConsole; eine Console öffen, um mit Write darin zu schreiben.
Mach ich oft für Debugausgaben