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

[Ñ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.

[[AgustinOrtu]]

Yo creo que lo mas pragmatico es tener constructores y destructores simples (por lo general yo no redefino destructores). Si se tienen constructores simples que lo unico que hacen es asignar los valores que reciben, pero no crean objetos, entonces la forma #3 es totalmente segura

Con esto me refiero a que, en lugar de que un objeto cree un descendiente de TStream (lo cual puede tener complicaciones), mejor que lo reciba ya correctamente inicializado; de este modo, el no tendra que tambien ser responsable de saber como crear el stream, que hacer si no se puede crear, ni responsable de destruirlo

[fremen]

Empezado por AgustinOrtu

Yo creo que lo mas pragmatico es tener constructores y destructores simples (por lo general yo no redefino destructores). Si se tienen constructores simples que lo unico que hacen es asignar los valores que reciben, pero no crean objetos, entonces la forma #3 es totalmente segura

Con esto me refiero a que, en lugar de que un objeto cree un descendiente de TStream (lo cual puede tener complicaciones), mejor que lo reciba ya correctamente inicializado; de este modo, el no tendra que tambien ser responsable de saber como crear el stream, que hacer si no se puede crear, ni responsable de destruirlo

Creo que no te he entendido bien... lo que sugieres es que el encapsulamiento de objetos, no es una buena idea???

[[AgustinOrtu]]

Empezado por fremen

Creo que no te he entendido bien... lo que sugieres es que el encapsulamiento de objetos, no es una buena idea???

No, justamente es lo contrario

[fremen]

Empezado por AgustinOrtu

No, justamente es lo contrario

Ok. Ya entendí.

Aunque veo sus ventajas a este patrón, a mi personalmente no me convence. Pero para gustos, colores. Y otra cosa no, pero colores en programación tenemos cientos...

[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

[roman]

Empezado por fremen

Te expongo mi caso "raro"

Este caso raro es más bien un caso erróneo: estás haciendo referencia a tus objetos A1 y A2 fuera del bloque try-except que está justamente para protegerlos. Además, la sección finally se usa para liberar los objetos por lo que es un error querer usarlos fuera de esa cláusula.

LineComment Saludos

[fremen]

Empezado por roman

Este caso raro es más bien un caso erróneo: estás haciendo referencia a tus objetos A1 y A2 fuera del bloque try-except que está justamente para protegerlos. Además, la sección finally se usa para liberar los objetos por lo que es un error querer usarlos fuera de esa cláusula.

LineComment Saludos

Esta claro que es un caso erroneo... pero que tire la primera piedra el que no ha tenido casos erroneos... puede que yo tenga demasiados y por eso hago este tipo de bloques try-finally, para cazar los errores antes de llevarlos a producción.

[Casimiro Notevi]

Empezado por fremen

... por eso hago este tipo de bloques try-finally, para cazar los errores antes de llevarlos a producción.

Es que no es la forma de hacerlo. No necesitas "cazar un error" que tú mismo estás provocando. Simplemente no provoques ese error.