Bloques Try-Finally para proteger múltiples recursos en Delphi (Traducción)

[fremen]

Empezado por Ñuño Martínez

Tu solución, fremen, es redundante (que no mala). Lo digo porque ya el método "Free" comprueba si el objeto existe (hay un "IF Self <> Nil", si no recuerdo mal), al igual que en FreeAndNil. Eso sí, el uso de FreeAndNil me gusta, y yo lo uso bastante, aunque no suelo poner el "IF Assigned" delante.

Es redundante según la casuística. Pero con esta estructura, todos los casos los tengo controlados. Te expongo mi caso "raro"

El porque del FreeAndNil.

var
  A1, A2: TTest;
begin
  A2 := nil;
  A1 := nil;  
  try
    A1 := TTest.Create;
    A2 := TTest.Create;
    //Use A1 and A2
  finally
    if Assigned(A2) then FreeAndNil(A2);
    A1.Free;
  end;
  // Aquí A2 siempre es Nil. Así, si tengo un descuido tal que... 
  A2.Propiedad_X := 1;   // Genera excepción siempre y en el periodo de pruebas lo detecto a la primera  
 
  // Aquí A1 tiene un valor indeterminado. 
  A1.Propiedad_X := 1;   // Según el estado de la memoria que apunte A1, unas veces generara excepción y otras no. Resultado: Errores aleatorios
end;

El Assigned, es simplemente porque FreeAndNil no esta protegido ante un parámetro a Nil. Este es el código en un XE7

procedure FreeAndNil(var Obj);
{$IF not Defined(AUTOREFCOUNT)} 
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;                  => Error
  Temp.Free;
end;
{$ELSE}
begin
  TObject(Obj) := nil;                => Error
end;
{$ENDIF}

Larga vida a Delphi ejejeje