Zwei Objekte in einem oder zwei Try Finaly Blöcke?

[Popov]

Ich hab mich schon immer gefragt wie andere hier das mit dem Try Finally Block machen. Guckt man sich fremden Code an, bekommt jedes Objekt oft seinen eigenen Block. Das habe ich mir irgendwann so abgeguckt und mache es auch:

Delphi-Quellcode:

  Bmp := TBitmap.Create;
  try
    { Hier gibt es keinen Code }
    sl := TStringList.Create;
    try
      { Es gibt nur hier Code }
      //Hier gibt es einen Fehler
    finally
      sl.Free;
    end;
    { Hier gibt es keinen Code }
  finally
    Bmp.Free;
  end;

Allerdings denke ich mir manchmal, dass es Quatsch ist. Denn wenn es im oberen Beispiel mittendrin ein Error gibt, unterscheidet das System nicht zwischen Bitmap und StringList Error. Zuerst geht es zum sl-Finally, dann zum Bmp-Finally. Warum also nicht gleich so?

Delphi-Quellcode:

var
  Bmp: TBitmap;
  sl: TStringList;
begin
  Bmp := TBitmap.Create;
  sl := TStringList.Create;
  try
    { Es gibt nur hier Code }
    //Hier gibt es einen Fehler
  finally
    sl.Free;
    Bmp.Free;
  end;
end;

Wie gesagt, ich sehe die obere Variante sehr oft, nur sehe ich keinen Sinn drin.

[DeddyH]

Da ich mich nicht wiederholen will: http://forum.delphi-treff.de/index.p...verschachteln/

[uligerhardt]

Deleted - war Quatsch.

[QuickAndDirty]

Zitat:

Zitat von DeddyH (Beitrag 1297822)

Da ich mich nicht wiederholen will: http://forum.delphi-treff.de/index.p...verschachteln/

Werden Objekt-Variablen in Delphi nicht implizit mit nil initialisiert?

[Popov]

DeddyH, gute Erklärung, aber das Beispiel ist leicht konstruiert. Sehe ich eigentlich wie du, aber das Beispiel entspricht nicht ganz meinem Beispiel oben. Auch die Bemerkung von uligerhardt war ok, ist aber nun weg. Konstruiert, weil ich hier nicht TBitmap mit TIniFile kombiniert habe, sondern TBitmap mit TStringList. Da kracht es nicht bei der Initialisierung. Bei TIniFile kann es auch bei Create krachen, im oberen Beispiel eher nicht.

[BadenPower]

Beide Varianten sind Schrott, da der Finaly-Block nie erreicht wird, wenn es zum Beispiel in TBitmap.Create knallt.

[SMO]

Zitat:

Zitat von QuickAndDirty (Beitrag 1297827)

Zitat:

Zitat von DeddyH (Beitrag 1297822)

Da ich mich nicht wiederholen will: http://forum.delphi-treff.de/index.p...verschachteln/

Werden Objekt-Variablen in Delphi nicht implizit mit nil initialisiert?

Nein, lokale Variablen liegen auf dem Stack und werden nicht automatisch initialisiert, Ausnahmen sind managed types wie strings, dynamische Arrays und Interfaces.

Zitat:

Zitat von BadenPower (Beitrag 1297832)

Beide Varianten sind Schrott, da der Finaly-Block nie erreicht wird, wenn es zum Beispiel in TBitmap.Create knallt.

Der Finally-Block muss auch nicht erreicht werden, wenn es in TBitmap.Create knallt, insofern also kein Schrott.

Ich persönlich mag zu viele Verschachtelungen nicht. Zwei sind noch ok, aber für mehr bevorzuge ich diese Variante:

Delphi-Quellcode:

var
  Bmp: TBitmap;
  sl: TStringList;
begin
  Bmp := nil;
  sl := nil;
  try
    Bmp := TBitmap.Create;
    sl := TStringList.Create;
    { Es gibt nur hier Code }
    //Hier gibt es einen Fehler
  finally
    sl.Free;
    Bmp.Free;
  end;
end;

oder

Delphi-Quellcode:

var
  Bmp: TBitmap;
  sl: TStringList;
begin
  sl := nil;
  Bmp := TBitmap.Create;
  try
    sl := TStringList.Create;
    { Es gibt nur hier Code }
    //Hier gibt es einen Fehler
  finally
    sl.Free;
    Bmp.Free;
  end;
end;

[stahli]

Wegen strom- bzw netzwerkausfall schreibe ich mit dem Handy und suche deshalb mal nicht frühere threads raus. Aber meine Meinung:

Try ... finally fuer myobject.free macht m.e. nur selten Sinn.
Erwartete Probleme wie io-acceptions sollte man natürlich h abfangen und behandeln.
Aber jedes .create mit Einem Try zu schützen bringt m.e. nichts.
Das Programm ist ab der stelle ohnehin in einem undefinierten und fehlerhaften Zustand und sollte neu gestartet (und repariert) werden oder was auch immer. Ob da im Speicher noch eine objektleiche liegt ist dann auch egal.

Wie gesagt: Fehler behandeln ist wichtig. Free in finally zu legen (ohne sonstige massnahmen) bringt m.e. nix.

[Popov]

Na gut. Ich hab zwar noch nie erlebt, dass eine der oberen Klassen schon bei Create gekracht hat, aber anderseits soll es irgendwo auf der Welt mal kleine Hunde geregnet haben. Somit will ich nicht ausschließen, es mal vorkommen kann. Also die weiterhin erste Methode :thumb:

[DeddyH]

Nimm doch mal einen FileStream und versuch den auf ein schreibgeschütztes Medium schreiben zu lassen.

[BadenPower]

Zitat:

Zitat von SMO (Beitrag 1297833)

Der Finally-Block muss auch nicht erreicht werden, wenn es in TBitmap.Create knallt, insofern also kein Schrott.

Habe ich auch gerade bemerkt als ich auf dem Weg zum Kaffeholen war.

Und wir sprechen ja von "Finaly" und nicht von "Except".

[Popov]

DeddyH, du hast ja Recht. Nur habe ich im Eingangspost vergessen eine Einschränkung zu erwähnen: ich meinte die 08/15 Klassen ohne Parameter in Create, die zu einem Error führen können. Ich hab im Beispiel solche Klassen genommen, hab aber nicht erwähnt, dass es mit nur um die geht.

[DeddyH]

Ich persönlich habe mir angewöhnt, stets die Varianten zu nehmen, die immer funktionieren. Neben den Ressourcenschutzblöcken sind das Dinge wie z.B. Arrays immer von Low() bis High() zu durchlaufen. Das hat den Vorteil, dass ich mir um solche Dinge wie "Kann das überhaupt im Konstruktor knallen bei dieser Klasse?" überhaupt keinen Kopf machen muss, sondern immer einen einheitlichen Stil verfolgen kann.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1297845)

Ich persönlich habe mir angewöhnt, stets die Varianten zu nehmen, die immer funktionieren. Neben den Ressourcenschutzblöcken sind das Dinge wie z.B. Arrays immer von Low() bis High() zu durchlaufen. Das hat den Vorteil, dass ich mir um solche Dinge wie "Kann das überhaupt im Konstruktor knallen bei dieser Klasse?" überhaupt keinen Kopf machen muss, sondern immer einen einheitlichen Stil verfolgen kann.

Das unterschreibe ich mit :thumb:

Es ist mir egal ob die aktuelle Implementierung einer Klasse beim Erzeugen eine Exception wirft oder nicht. Alle werden gleich behandelt und ich muss mir weniger einen Kopf um Speicherlecks machen.

Bei der konsequenten Verfolgung kann die Anwendung auch nicht kaputt gehen, da ja alles wieder so ist wie vor dem Aufruf (und da war die ja noch nicht kaputt).

[Popov]

Ich widerspreche dir nicht. Mache ich im Grunde auch. Aber wann man mal wieder eine Prozedur hat bei der man paar Objekte auf einmal bracht, dann wird der Code lang, noch bevor man losgelegt hat.

Delphi-Quellcode:

var
  Bmp1, Bmp2, Bmp3, Bmp4, Bmp5: TBitmap;
begin
  Bmp1 := TBitmap.Create;
  try
    Bmp2 := TBitmap.Create;
    try
      Bmp3 := TBitmap.Create;
      try
        Bmp4 := TBitmap.Create;
        try
          Bmp5 := TBitmap.Create;
          try
            //Hier tue was
          finally
            Bmp5.Free;
          end;
        finally
          Bmp4.Free;
        end;
      finally
        Bmp3.Free;
      end;
    finally
      Bmp2.Free;
    end;
  finally
    Bmp1.Free;
  end;
end;

[DeddyH]

Da würde ich mir eher Gedanken machen, ob sich das nicht in kleinere Portionen aufteilen lässt.

[Sir Rufo]

@Popov

Da reicht genau ein

Delphi-Quellcode:

try finally

Block aus.

[himitsu]

Man muß auch nicht nur an den Constructor denken, sondern auch an den Destructor.

Delphi-Quellcode:

B := nil;
A := TMyClass.Create;
try
  B := TMyClass.Create;
  ...
finally
  A.Free;  // wenn es hier knallt, dann hat man ein Leck
  B.Free;
end;

Lösungen:
* doch nicht zusammenfassen

oder

Delphi-Quellcode:

finally
  B.Free;
  A.Free;  // wenn es hier knallt, dann ist es egal, aber es darf natürlich nicht schon in B.Free knallen
end;

oder so :roll:

Delphi-Quellcode:

finally
  try
    A.Free;
  finally
    B.Free;
  end;
end;

[Sir Rufo]

@himitsu

Das Erzeugen einer Klasse kann in die Hose gehen und ein völlig korrektes Verhalten der Klasse sein. Eine Exception im

Delphi-Quellcode:

destructor

ist immer ein absolutes Fehlverhalten der Klasse. Somit gehört dein Beispiel in die Kategorie "paranoide Programmierung".

[stahli]

Jetzt will ich doch nochmal einhaken (kann auch wieder am Rechner schreiben):

Delphi-Quellcode:

B := nil;
 A := TMyClass.Create;
try
   B := TMyClass.Create;
   EuroÜberweisenVonStahliZuHimi(B.Value);
finally
   A.Free; // wenn es hier knallt, dann hat man ein Leck
   B.Free;
end;

Wenn Du als Nutzer obiges Programm ausführst und B.Create knallt - warum auch immer - wirst Du mit dem Programm nicht glücklich werden.
Ob da noch Speicher allociert ist oder nicht, wäre da nebensächlich.

Du erfährst als Nutzer nicht, dass die Überweisung nicht funktioniert hat.
Ok, es wird kein Speicher verschwendet aber das ist doch sowas von egal.

Besser wäre, wenn es eine Fehlermeldung gibt. Entweder eine Schutzverletzung oder eine nette Erklärung wie "Die Überweisung konnte nicht durchgeführt werden!".
In jedem Fall muss die Software gefixt (oder einer neue Version verkauft :|) werden.

Liege ich da so falsch mit der Ansicht?

[DeddyH]

Meiner Meinung nach ja. Exceptions sind doch nichts Böses, soll man bei jedem Auftreten einer solchen das Programm neu starten? Oder einfach warten, bis der Speicher vollgelaufen ist?

[stahli]

Aber es geht doch hier offensichtlich um keine erwarteten Probleme.

Wenn ich eine Ini einlesen will und das Laufwerk existiert nicht, dann muss ich das berücksichtigen und das Problem behandeln (z.B. Standardwerte benutzen oder Hinweise ausgeben oder Programmteile sperren oder was auch immer).
Alles super. Es gibt verschiedene Wege. Den normalen Weg und in bestimmten Fällen Alternativen. Das Programm arbeitet wie vorgesehen.

Wenn aber TPanel.Create nicht funktioniert (warum auch immer - Speicher defekt, Virus, "Beta-Bugfix" vom Hersteller oder falsche Mondphase) dann bringt es nichts, das aufrufende Formular mit Free freizugeben.
Das Programm ist nicht funktionsfähig und muss schnellstens repariert werden.
Wenn der Kunde das Formular 1000 mal startet wird zwar der Speicher nicht so schön aufgeräumt wie mit finally aber da kommt es dann doch wirklich nicht mehr drauf an.
Mit Daten-Objekten wäre diese stillschweigende Fehlerunterdrückung noch schlimmer, da der User dann u.U. gar nicht merkt, dass irgendwas nicht funktioniert.

[DeddyH]

Irgendwie habe ich das Gefühl, dass Du finally mit except verwechselst.

[stahli]

Glaube ich eigentlich nicht.
Der finally- Block wird in jedem Fall ausgeführt, auch wenn es in try knallt. Richtig?
Aber die erwartete Überweisung wird nicht durchgeführt und es erfolgt kein Fehlerhinweis.

--> oder unterdrückt finally die Fehlermeldung nicht - dann läge ich tatsächlich falsch

Aber selbst dann würde ich solch ein Konstrukt nur für sinnvoll halten, wenn ein Problem an der Stelle zumindest denkbar ist.

Delphi-Quellcode:

B := nil;
A := TMyClass.Create;
try
    B := TMyClass.Create; // wenn es hier knallt geht es nach finally weiter, die Überweisung wird aber nicht ausgeführt und keiner kriegt es mit
    EuroÜberweisenVonStahliZuHimi(B.Value);
finally
    A.Free; 
    B.Free;
end;

[DeddyH]

Zitat:

Zitat von stahli (Beitrag 1297871)

--> oder unterdrückt finally die Fehlermeldung nicht - dann läge ich tatsächlich falsch

Einfach mal ausprobieren ;)

Delphi-Quellcode:

procedure TFormTrallalla.ButtonBummsClick(Sender: TObject);
var
  Dings: TStringlist;
begin
  Dings := TStringlist.Create;
  try
    Dings.Add('Wuppdi');
    ShowMessage(Dings[1]);
  finally
    Dings.Free;
  end;
end;

Ohne Debugger starten und schauen, ob da eine Meldung kommt.

[stahli]

[OT] Kann ich erst später, sonst hätte ich natürlich nicht gefragt. [/OT]

[DeddyH]

Dann sage ich es Dir einfach: es kommt eine Meldung "Listenindex überschreitet das Maximum(0)". Finally fängt eben keine Fehler ab, dazu ist except da, sondern wird nur garantiert durchlaufen, sobald man den dazugehörigen try-Block betreten hat. Man nennt dieses Konstrukt daher ja auch Ressourcenschutzblock.

[Popov]

@stahli

Vielleicht bringe ich mal einen anderen Betrachtungspunkt in das Spiel. Ein Beispiel:

Delphi-Quellcode:

type
  TTest = class
  public
    constructor Create;
  end;

constructor TTest.Create;
begin
  raise Exception.Create('Fehler');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Test: TTest;
begin
  Test := TTest.Create;
  try
    ShowMessage('Im Try');
    Abort;
  finally
    ShowMessage('Im Finally');
    Test.Free;
  end;
end;

In Create wird eine Exception ausgelöst. Hier ist es unwichtig ob es einen Try Finally oder gar Try Exception Block gibt. Der kommt erst gar nicht ins Spiel. Macht es in Create Krachbumm, wird der Fehler intern abgewickelt, bzw. es geht intern sofort zum Destructor. Try Finally ist für Fehler gedacht die später kommen.

[HeZa]

@stahli

ein finally verschluckt keine Exception!

Delphi-Quellcode:

sl := TStringlist.Create;
try
  raise Exception.Create('No chance');
finally
  sl.Free;
end;

sl.Free wird, wie du ja gesagt hast immer ausgeführt. Wenn finally ausgeführt wird, während eine Exception läuft, wird nach der Ausführung des finally-Bolcks, die Exception trotzdem weiter geworfen.

Mit anderen Worten: Finally schützt deine Resourcen, erlöst dich aber nicht von der Exception.

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1297865)

Wenn Du als Nutzer obiges Programm ausführst und B.Create knallt - warum auch immer - wirst Du mit dem Programm nicht glücklich werden.
Ob da noch Speicher allociert ist oder nicht, wäre da nebensächlich.

Du erfährst als Nutzer nicht, dass die Überweisung nicht funktioniert hat.
Ok, es wird kein Speicher verschwendet aber das ist doch sowas von egal.

Besser wäre, wenn es eine Fehlermeldung gibt. Entweder eine Schutzverletzung oder eine nette Erklärung wie "Die Überweisung konnte nicht durchgeführt werden!".
In jedem Fall muss die Software gefixt (oder einer neue Version verkauft :|) werden.

Natürlich sollte man einen Fehler bei der Überweisung abfangen und entsprechend reagieren. Es könnte ja ganz einfach sein, daß das Konto nicht gedeckt ist. Dann hilft auch eine neue Programmversion nicht weiter, da die Software ja nicht die Ursache des Fehlers ist.

Es könnte aber sein, daß TMyClass irgendwelche Resourcen anfordert (z.B. eine Verbindung zum Bankrechner), die es im Destruktor wieder freigibt. Dann sollte das finally aber ganz sicher durchlaufen werden. Es ist dabei sogar möglich, daß im Destroy eine Exception geworfen wird, die darauf hinweist, daß z.B. diese Verbindung nicht sauber geschlossen werden konnte. Also können auch Aufrufe wie B.Free noch eine Exception werfen. Nicht immer hat man auch die Kontrolle über diese Klassen, wenn die z.B. aus einer Bibliothek kommen.

Ich würde mich also in keinem Fall darauf verlassen, daß ein Create oder Destroy schon keine Exception auslöst.

[himitsu]

Ich hatte letztens eine Stream-Klasse, welche bei Schreiben über einen Cache läuft.
Wenn beim Destroy noch was im Cache ist, wird das versucht zu schreiben.
Da kann es natürlich genauso krachen, wie bei vorherrigen Schreibzugriffen.