Cita:
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.
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