Ver Mensaje Individual
  #8  
Antiguo 12-02-2018
fremen fremen is offline
Miembro
 
Registrado: sep 2010
Posts: 20
Reputación: 0
fremen Va por buen camino
Cita:
Empezado por Ñuño Martínez Ver Mensaje
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.
Código:
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
Código:
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
Responder Con Cita