Bewährte Praxis für verschachtelte TRY / FINALLY-Anweisungen

Question

Hallo Was ist der beste Weg, um verschachtelte Try & finally-Anweisungen in Delphi zu tun?

var cds1  : TClientDataSet;
    cds2  : TClientDataSet;
    cds3  : TClientDataSet;
    cds4  : TClientDataSet;
begin
  cds1      := TClientDataSet.Create(application );
  try
    cds2      := TClientDataSet.Create(application );
    try
      cds3      := TClientDataSet.Create(application );
      try
        cds4      := TClientDataSet.Create(application );
        try
        ///////////////////////////////////////////////////////////////////////
        ///      DO WHAT NEEDS TO BE DONE
        ///////////////////////////////////////////////////////////////////////
        finally
          cds4.free;
        end;

      finally
        cds3.free;
      end;
    finally
      cds2.free;
    end;
  finally
    cds1.free;
  end;
end;

Können Sie eine bessere Lösung vorschlagen?

Answer 1

Wie wäre es mit folgendem:

var cds1  : TClientDataSet;
    cds2  : TClientDataSet;
    cds3  : TClientDataSet;
    cds4  : TClientDataSet;
begin
  cds1      := Nil;
  cds2      := Nil;
  cds3      := Nil;
  cds4      := Nil;
  try
    cds1      := TClientDataSet.Create(nil);
    cds2      := TClientDataSet.Create(nil);
    cds3      := TClientDataSet.Create(nil);
    cds4      := TClientDataSet.Create(nil);
    ///////////////////////////////////////////////////////////////////////
    ///      DO WHAT NEEDS TO BE DONE
    ///////////////////////////////////////////////////////////////////////
  finally
    freeandnil(cds4);
    freeandnil(cds3);
    freeandnil(cds2);
    freeandnil(Cds1);
  end;
end;

Dadurch bleibt es kompakt und es wird nur versucht, die Instanzen freizugeben, die erstellt wurden. Es besteht wirklich keine Notwendigkeit, die Verschachtelung durchzuführen, da JEDER Fehler zu einem Rückfall auf die letzte Instanz führt und alle Aufräumarbeiten in dem von Ihnen angegebenen Beispiel durchgeführt werden.

Ich persönlich versuche, innerhalb derselben Methode keine Verschachtelungen vorzunehmen... mit der Ausnahme, dass ein try/try/except/finally-Szenario vorliegt. Wenn ich finde, dass ich verschachteln muss, dann ist das für mich ein guter Zeitpunkt, um über eine Umstrukturierung in einen anderen Methodenaufruf nachzudenken.

EDIT Ein bisschen aufgeräumt dank der Kommentare von mghie y utku .

EDIT die Objekterstellung so geändert, dass sie nicht auf die Anwendung verweist, da dies in diesem Beispiel nicht erforderlich ist.

Answer 2

Ich würde etwa so vorgehen:

var
  Safe: IObjectSafe;
  cds1 : TClientDataSet;
  cds2 : TClientDataSet;
  cds3 : TClientDataSet;
  cds4 : TClientDataSet;
begin
  Safe := ObjectSafe;
  cds1 := Safe.Guard(TClientDataSet.Create(nil)) as TClientDataSet;
  cds2 := Safe.Guard(TClientDataSet.Create(nil)) as TClientDataSet;
  cds3 := Safe.Guard(TClientDataSet.Create(nil)) as TClientDataSet;
  cds4 := Safe.Guard(TClientDataSet.Create(nil)) as TClientDataSet;
  ///////////////////////////////////////////////////////////////////////
  ///      DO WHAT NEEDS TO BE DONE
  ///////////////////////////////////////////////////////////////////////

  // if Safe goes out of scope it will be freed and in turn free all guarded objects
end;

Für die Implementierung der Schnittstelle siehe ce Artikel, aber Sie können etwas Ähnliches leicht selbst erstellen.

EDIT:

Mir ist gerade aufgefallen, dass in dem verlinkten Artikel Guard() eine Prozedur ist. In meinem eigenen Code habe ich Guard()-Funktionen überladen, die TObject zurückgeben, obiger Beispielcode geht von etwas Ähnlichem aus. Natürlich mit Generika viel besser Code ist jetzt möglich...

EDIT 2:

Wenn Sie sich fragen, warum try ... finally in meinem Code vollständig entfernt ist: Es ist unmöglich, die verschachtelten Blöcke zu entfernen, ohne die Möglichkeit von Speicherlecks (wenn Destruktoren Ausnahmen auslösen) oder Zugriffsverletzungen einzuführen. Daher ist es am besten, eine Hilfsklasse zu verwenden und die Referenzzählung der Schnittstellen vollständig zu übernehmen. Die Hilfsklasse kann alle von ihr bewachten Objekte freigeben, selbst wenn einige der Destruktoren Ausnahmen auslösen.

Answer 3

Es gibt noch eine andere Variante des Codes ohne verschachteltes Try ... schließlich ist mir das gerade eingefallen. Wenn Sie die Komponenten nicht mit dem AOwner-Parameter des Konstruktors, der auf Null gesetzt ist, erstellen, dann können Sie einfach die Lebenszeitverwaltung nutzen, die Ihnen die VCL kostenlos zur Verfügung stellt:

var
  cds1: TClientDataSet;
  cds2: TClientDataSet;
  cds3: TClientDataSet;
  cds4: TClientDataSet;
begin
  cds1 := TClientDataSet.Create(nil);
  try
    // let cds1 own the other components so they need not be freed manually
    cds2 := TClientDataSet.Create(cds1);
    cds3 := TClientDataSet.Create(cds1);
    cds4 := TClientDataSet.Create(cds1);

    ///////////////////////////////////////////////////////////////////////
    ///      DO WHAT NEEDS TO BE DONE
    ///////////////////////////////////////////////////////////////////////

  finally
    cds1.Free;
  end;
end;

Ich bin ein großer Verfechter von kleinem Code (wenn er nicht zu verworren ist).

Answer 4

Wenn Sie diesen (IMO) hässlichen Weg gehen wollen (Gruppenbehandlung mit Initialisierung auf nil, um zu wissen, ob das Freigeben erforderlich ist), MÜSSEN Sie zumindest garantieren, dass Sie nicht zulassen, dass eine Ausnahme in einem der Destruktoren das Freigeben der restlichen Objekte verhindert.
Etwa so:

function SafeFreeAndNil(AnObject: TObject): Boolean;
begin
  try
    FreeAndNil(AnObject);
    Result :=  True;
  except
    Result := False;
  end;
end;

var cds1  : TClientDataSet;
    cds2  : TClientDataSet;
    IsOK1 : Boolean;
    IsOK2 : Boolean;
begin
  cds1      := Nil;
  cds2      := Nil; 
 try
    cds1      := TClientDataSet.Create(nil);
    cds2      := TClientDataSet.Create(nil);    
    ///////////////////////////////////////////////////////////////////////
    ///      DO WHAT NEEDS TO BE DONE
    ///////////////////////////////////////////////////////////////////////
  finally
    IsOk2 := SafeFreeAndNil(cds2);    // an error in freeing cds2 won't stop execution
    IsOK1 := SafeFreeAndNil(Cds1);
    if not(IsOk1 and IsOk2) then
      raise EWhatever....
  end;
end;

Answer 5

Es gibt ein gutes Video auf Ausnahmen in Konstruktoren und Destruktoren

Sie zeigt einige schöne Beispiele, wie zum Beispiel:

var cds1  : TClientDataSet;
    cds2  : TClientDataSet;
begin
  cds1      := Nil;
  cds2      := Nil; 
 try
    cds1      := TClientDataSet.Create(nil);
    cds2      := TClientDataSet.Create(nil);    
    ///////////////////////////////////////////////////////////////////////
    ///      DO WHAT NEEDS TO BE DONE
    ///////////////////////////////////////////////////////////////////////
  finally
    freeandnil(cds2);    //// what has if there in an error in the destructor of cds2
    freeandnil(Cds1);
  end;
end;

Was ist, wenn es einen Fehler im Destruktor von cds2 gibt?

Cds1 wird nicht vernichtet

EDIT

Eine weitere gute Quelle ist :

Jim McKeeth ausgezeichnetes Video über Verzögerte Ausnahmebehandlung in Codebereich III, wo er über Probleme bei der Behandlung von Ausnahmen im Finally-Block spricht.