delphi - La mejor práctica para hacer una declaración TRY/FINALY anidada

memory-management object-lifetime

Question

Hola, ¿cuál es la mejor manera de hacer declaraciones try y finally anidadas en delphi?

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;

¿Puedes sugerir una mejor manera de hacer esto?

Answer 1

¿qué tal lo siguiente?

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;

Esto lo mantiene compacto, y solo intenta liberar las instancias que se crearon. Realmente no hay necesidad de realizar el anidamiento, ya que CUALQUIER falla dará como resultado finalmente la finalización y la realización de toda la limpieza en el ejemplo que proporcionó.

Personalmente trato de no anidar dentro del mismo método ... con la excepción de un escenario try / try / except / finally. Si encuentro que necesito anidar, entonces para mí ese es un buen momento para pensar refactorizar en otra llamada a método.

EDIT Se mghie un poco gracias a los comentarios de mghie y utku .

EDIT cambió la creación del objeto para que no sea una aplicación de referencia, ya que no es necesario en este ejemplo.

Answer 2

@mghie: Delphi tiene objetos asignados de pila:

type
  TMyObject = object
  private
    FSomeField: PInteger;
  public
    constructor Init;
    destructor Done; override;
  end;

constructor TMyObject.Init;
begin
  inherited Init;
  New(FSomeField);
end;

destructor TMyObject.Done;
begin
  Dispose(FSomeField);
  inherited Done;
end;

var
  MyObject: TMyObject;

begin
  MyObject.Init;
  /// ...
end;

Lamentablemente, como se muestra en el ejemplo anterior, los objetos asignados a la pila no evitan fugas de memoria.

Así que esto aún requeriría una llamada al destructor de esta manera:

var
  MyObject: TMyObject;

begin
  MyObject.Init;
  try
    /// ...
  finally
    MyObject.Done;
  end;
end;

De acuerdo, lo admito, esto está muy fuera del tema, pero pensé que podría ser interesante en este contexto ya que los objetos asignados a la pila se mencionaron como una solución (que no lo son si no hay una llamada automática al destructor).

Answer 3

Hay otra variación del código sin intento anidado ... finalmente eso solo se me ocurrió. Si no crea los componentes con el parámetro AOwner del constructor establecido en cero, entonces simplemente puede hacer uso de la administración de por vida que la VCL le da de forma gratuita:

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;

Soy un gran creyente en el código pequeño (si no está demasiado ofuscado).

Answer 4

Hay un buen video sobre excepciones en constructores y destructores

Muestra algunos buenos ejemplos tales como:

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;

¿Qué pasa si hay un error en el destructor de cds2?

Cds1 no será destruido

EDITAR

Otro buen recurso es:

Jim McKeeth excelente video sobre el manejo de excepciones retrasadas en el rango de código III cuando habla de problemas en el manejo de excepciones en el bloque final.

Answer 5

Si quieres ir por esta (IMO) ruta desagradable (gestión de grupos con inicialización a cero para saber si es necesario liberar), al menos DEBES garantizar que no permitas que una excepción en uno de los destructor impida liberar el resto de tus objetos
Algo como:

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 6

Yo usaría algo como esto:

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;

Para la implementación de la interfaz, consulte this artículo, pero puede crear fácilmente algo similar usted mismo.

EDITAR:

Acabo de notar que en el artículo vinculado Guard () es un procedimiento. En mi propio código he sobrecargado las funciones de Guard () que devuelven TObject, el código de ejemplo anterior asume algo similar. Por supuesto, con los genéricos, ahora es posible un código mucho mejor ...

EDICION 2:

Si se pregunta por qué lo intento ... finalmente se elimina por completo en mi código: es imposible eliminar los bloques anidados sin introducir la posibilidad de pérdidas de memoria (cuando los destructores generan excepciones) o violaciones de acceso. Por lo tanto, es mejor utilizar una clase de ayuda y dejar que el recuento de referencias de las interfaces se haga cargo por completo. La clase auxiliar puede liberar todos los objetos que protege, incluso si algunos de los destructores generan excepciones.