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

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