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

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

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 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;