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

Entrada original (En ingés)

El lenguaje Delphi comparte con muchos otros un patrón de asignación de recursos estándar para garantizar que, en el caso de una excepción, los recursos se liberen de forma adecuada. Los recursos en este contexto son objetos de memoria, archivos,
objetos y manejadores del sistema operativo, y similares. En Delphi, en comparación con otros lenguajes con un recolector de basura, la relevancia aumentó por consideraciones de administración de memoria.

Protegiendo un solo objeto

En los casos más simples, escribirías código como:

Código Delphi [-]
Asignar recurso 
try 
  usar recurso 
finally 
  liberar recurso 
end;

Un ejemplo más específico sería como:

Código Delphi [-]
A1: = TTest.Create; 
try 
  A1.DoSomething; 
finally
  A1.Free; 
end;

Hasta aquí todo bien. Tenga en cuenta que si se produce un error durante la ejecución del constructor, Delphi ejecutará automáticamente el destructor para el objeto parcialmente inicializado (pero este podría ser un tema para otra publicación de blog).


Protección de dos objetos: cómo NO escribir el código

El problema en el que me quiero enfocar es cómo escribir el mismo tipo de código si necesita asignar y eliminar dos recursos. Aquí hay múltiples opciones. Lo que no debes hacer (pero es bastante común) es escribir:

Código Delphi [-]
A1 := TTest.Create; 
A2 := TTest.Create; 
try 
  A1.DoSomething; 
  A2.DoSomething(A1); 
finally 
  A2.Free; 
  A1.Free; 
end;

El problema con este código es que, en caso de que falle la creación de A2 (y podría haber muchas razones), el objeto A1 permanecería en la memoria. Y simplemente colocar la segunda asignación dentro del bloque TRY tampoco es bueno:

Código Delphi [-]
A1 := TTest.Create; 
try 
  A2 := TTest.Create; 
  A1.DoSomething; 
  A2.DoSomething(A1); 
finally 
  A2.Free; 
  A1.Free; 
end;

Con este código en caso de una falla en la llamada al constructor del objeto A2, el bloque finally intentará liberar un objeto no inicializado (el valor predeterminado de una referencia de objeto local no está definido). Esta es la razón por la cual una posible solución es establecer A2 a cero al comienzo, ya que llamar Free en un objeto nulo no tiene ningún efecto. O configurar todas las referencias de objetos como nulas para simplificar y uniformizar. O escriba dos bloques try anidados para proteger cada uno de los recursos.


Protección de dos objetos: una historia de tres soluciones

Esta larga introducción nos lleva al punto de esta publicación de blog. Hay al menos 3 soluciones correctas diferentes para la protección de dos recursos en el mismo bloque de código, como acabo de mencionar. Estas son las tres soluciones que "tomé prestada" de uno de nuestros arquitectos de RAD Studio R & D, Bruneau Babet.

#1

Código Delphi [-]
var
  A1, A2: TTest;
begin
  A1 := TTest.Create;
  try
    A2 := TTest.Create;
    try
      //Use A1 and A2
    finally
      A2.free;
    end;
  finally
    A1.free;
  end;
end

#2

Código Delphi [-]
var
  A1, A2: TTest;
begin
  A2 := nil;
  A1 := TTest.Create;
  try
    A2 := TTest.Create;
    //Use A1 and A2
  finally
    A2.free;
    A1.free;
  end;
end

#3

Código Delphi [-]
var
  A1, A2: TTest;
begin
  A2 := nil;
  A1 := nil;  
  try
    A1 := TTest.Create;
    A2 := TTest.Create;
    //Use A1 and A2
  finally
    A2.free;
    A1.free;
  end;
end

Siempre que todos sean correctos en términos de gestión de recursos adecuada en todos los escenarios, ¿cuáles son las ventajas y desventajas de estas 3 soluciones? Lo que es importante considerar es que los 2 recursos podrían ser 3, o 4 o media docena.

¿Cuál elegir?
La primera solución con los bloques de intentos anidados es bastante limpia pero más detallada (más líneas de código) y tiene anidamiento adicional que podría convertirse en una molestia con múltiples recursos. Además, hay un costo de tiempo de ejecución asociado con los bloques try, claramente limitado pero no cero.

La segunda solución tiene la menor cantidad de líneas de código y la menor cantidad de tiempo de ejecución. El único adicional es configurar A2 a nil. El código sigue siendo legible también con muchos recursos. Sin embargo, el código es "desequilibrado" y podría ser un poco confuso.

La tercera solución va en la misma dirección, pero agrega una asignación adicional técnicamente inútil a nil (para A1), ofreciendo la ventaja de ser más limpio y más equilibrado, y probablemente más legible después de todo.

Entonces, ¿cuál es la mejor solución? Esto es realmente difícil de decir. Personalmente usé principalmente el número 1 en mis libros, pero en Embarcadero tendemos a preferir los más limpios y más rápidos (es decir, los n. ° 2 o n. ° 3) para el código de la biblioteca

Alguna vez discutimos esto por aquí. Yo uso (o usaba) la tercera opción desde que la vi mencionada -no recuerdo si por Marco Cantú o por Peter Below. Me parece la más limpia y simétrica. La versión anidada es horrible ya que habría que agregar una anidación por cada objeto.

No obstante, hay quienes objetan la tercera opción (me acuerdo de Al González) ya que el destructor de A2 podría causar una excepción y dejar A1 sin liberar. Pero, como decía el mismo Cantú o Below, un destructor no debe nunca, pero NUNCA, causar una excepción. Y si la causa significa un mal diseño que hay que corregir antes que preocuparse por A1.

LinneComment Saludos

Ya encontré la discusión :)

http://clubdelphi.com/foros/showthread.php?t=59241

LineComment Saludos

Eso de buscarse a uno mismo en Google tiene sus sorpresas, je-je-je.

¡Un gran saludo, Román! :)

Hola... yo siempre uso el metodo 3, pero asegurando mas el finally

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.

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

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.
El Assigned, es simplemente porque FreeAndNil no esta protegido ante un parámetro a Nil. Este es el código en un XE7
Larga vida a Delphi ejejeje

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

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

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.

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