try .. except .. finally

[Surrounder]

Warum kann ich eigentlich wenn ich einen try benutze nicht einen except und ein finally verwenden?

Ich schreibe in eine Datei die auch schreibgeschützt sein kann, und dann kommt es zu einem Fehler. Ich würde gerne wenn es zu dieser Exception kommt eine Meldung in mein Logfile schreiben, aber dann trotzdem im finally das File wieder schließen.

Momentan gehe ich einfach her und mache zwei try hintereinandern, mich würde nur interessieren ob mir jemand sagen kann warum try .. except .. finally als ganzes nicht geht?!?

Delphi-Quellcode:

var
   ppFile : TNativeXML;
   node : TXMLNode;
begin
   try
      try

         ppFile := TNativeXml.CreateName('xyz');

         node := ppFile.Root.NodeNew( 'test123' );
         with node do begin
            WriteString( 'x', x);
            WriteInteger( 'y', y);

         end;

      except
         AddLogAlert( 'Fehler' );
      end;
   finally
      ppFile.Free;
   end;
end;

[Stormy]

Ist so weil darum könnte man jetzt einfach sagen. Sind eben zwei uterschiedliche Befehle. Da müsstest du dich auch fragen warm man bei Case nicht auch of und in gleichzeitig benutzen kann.


Gruß
Stormy

[MStoll]

Hi,

stelle dir einfach die Frage: wofür brauchst du den finally-Block, wenn du ein try...except unmittelbar davor hast?
Dadurch, dass alles davor abgefangen ist, wird das, was nach dem try...except-Block kommt, auf (fast) jeden Fall ausgeführt. Einzige Ausnahme: du hast im except-Teil wieder eine Exception.

Gruß
Michael

[Edit]Zumal: deine Verwendung der try-Blöcke ist nicht ganz im Sinne des Erfinders: was passiert denn, wenn's bei ppFile := TNativeXml.CreateName('xyz') zu einer Exception kommt?[/Edit]

[Surrounder]

Zitat von MStoll:

Hi,

stelle dir einfach die Frage: wofür brauchst du den finally-Block, wenn du ein try...except unmittelbar davor hast?
Dadurch, dass alles davor abgefangen ist, wird das, was nach dem try...except-Block kommt, auf (fast) jeden Fall ausgeführt. Einzige Ausnahme: du hast im except-Teil wieder eine Exception.

Gruß
Michael

Und für welchen Fall brauche ich dann überhaupt try .. finally?

[Regan]

Zitat von Surrounder:

Und für welchen Fall brauche ich dann überhaupt try .. finally?

Damit etwas auf jeden Fall passiert. In deinem Fall zum Beispiel müssen die Variablen freigegeben werden. Für eine StringList sieht sowas dann ungefähr so aus:

Delphi-Quellcode:

begin
  MySringList := TStringList.Create();
  try
    //hier käme dann anderer Code
  finally
    MyStringList.Free();
  end;
end;

So kannst du sicher gehen, dass auf jeden Fall der Speicher freigegeben wird, egal, was passiert.

Edit1: Kosmetik.
Edit2:

Das except ist im Endeffekt nur für Fehler, die du nicht selber abfangen kannst (z. B. bei falschen Rückmeldungen durch Server etc.). Gegen andere Dinge (Datei existiert, Datei zu groß/zu klein/nicht gültig) kannst du dich schützen.

[angos]

Hi,

So herum ist es richtig.

Delphi-Quellcode:

[...]
begin
   ppFile := TNativeXml.CreateName('xyz');
   try
      try
         [...]
      except
         AddLogAlert( 'Fehler' );
      end;
   finally
      ppFile.Free;
   end;
end;

Ich frage mich allerdings noch immer, wozu du try except finally zusammen in einem Block brauchst. Nacheinander wird es doch sauber ausgeführt. Sehe da kein Problem. Das finally sollte in dem obigen Beispiel in jedem Fall ausgeführt werden.

Edit: nur nochmal um es als Info zusammenzufassen:

- finally dient dazu, einen Code in jedem Fall durchzuführen, zB zum Freigeben von Objekten
- except dient dazu, Fehler abzufangen und zu verarbeiten


Gruß
Ansgar

[Surrounder]

Zitat von angos:

Hi,

So herum ist es richtig.

Gruß
Ansgar

Dass es so richtig ist weiss ich, es funktionier ja auch. Ich wollte ja wissen warum es nicht wie folgt geht:

Delphi-Quellcode:

begin
   ppFile := TNativeXml.CreateName('xyz');
   try
         [...]
   except
         AddLogAlert( 'Fehler' );
   finally
      ppFile.Free;
   end;
end;

[angos]

kurz und knapp: Nein. Ich sehe aber auch keinen sinn darin...außer dich drei buchstaben zu sparen

edit: in deinem Code oben hattest du die Erstellung des Objektes nach dem ersten try durchgeführt. Ist imho nicht ganz sauber, das sollte schon vor dem ersten "try" erzeugt werden. Nur darauf wollte ich mit meinem Codeschnipsel hinweisen

[Surrounder]

Zitat von angos:

kurz und knapp: Nein. Ich sehe aber auch keinen sinn darin...außer dich drei buchstaben zu sparen

edit: in deinem Code oben hattest du die Erstellung des Objektes nach dem ersten try durchgeführt. Ist imho nicht ganz sauber, das sollte schon vor dem ersten "try" erzeugt werden. Nur darauf wollte ich mit meinem Codeschnipsel hinweisen

Ah ok, das ist weil ich das als Beispiel schnell für das Post zusammenkopiert habe

Naja der Sinn darin wäre dass wenn ich z.B. beim schreiben in die Datei eine exception bekomme diese abfangen kann bzw. eine klare Fehlermeldung dazu ausgeben und ins logifle schreiben kann. Trotzdem will ich wenn die Exception kommt dass die Datei / Stringlist oder was auch immer definitive geschlossen wird. Das schließen soll aber natürlich auch wenn keine Exception kommt passieren (was ich normal im finally mache).

Aber es ist ok, ich kann damit leben dass ich drei Zeichen mehr tippen muss

[Muetze1]

Zitat von angos:

So herum ist es richtig.

Wieso sollte? Wer sagt dir das?

Ich kann Exception des gesamten Blockes auch noch später abfangen, also warum sollte es nun richtig sein den Except Block innerhalb des Finallys zu haben? Bitte gebe mir mindestens eine schlüssige Begründung dazu.

Und wo wir gerade dabei sind an alle Leser nochmal ein Hinweis über einen gerne gemacht Fehler in diesem Zusammenhang:

Delphi-Quellcode:

var
  lFile: TNativeXML;
begin
   try
     lFile := TNativeXml.CreateName('xyz');
     [...]
   finally
      FreeAndNil(lFile);
   end;
end;

In dieser Konstellation gibt Delphi keine Warnung aus, dass die Variable lFile möglicherweise nicht initialisiert worden ist.

Delphi-Quellcode:

var
  lFile: TNativeXML;
begin
   try
     lFile := TNativeXml.CreateName('xyz');
     [...]
   finally
      lFile.Free;
   end;
end;

So rum schon.

Der Fehler das Create in das try zu schieben wird oft und gerne gemacht. Auch ist die Frage der Anwendung des FreeAndNil() auf eine lokale Variable fraglich, aber FreeAndNil() ist besser und sicherer - steht an vielen Ecken. Damit wird es oftmals auch sehr oft eingesetzt. Im zweiten Falle kommt die Warnung von Delphi und es fällt auf, dass der Constructor Aufruf innerhalb des try/finally steht. Wenn aber nun FreeAndNil() verwendet wird, dann nicht. Hintergrund ist einfach nur, dass FreeAndNil() einen var Parameter und damit kann der Compiler dies nicht mehr erkennen, da die Funktion die Variable innerhalb ihrer belegen kann.

FYI