try-try-finally-finally

[[Al González]]

¡Hola!

Empezado por roman

Al, las líneas que moviste, de hecho, es esencial que permanezcan donde estaban ...

Bueno, es que de hecho ninguna de las variantes expuestas de la forma compacta son más seguras y válidas que la forma anidada.

Sólo que pensé que deseabas escribir la forma compacta al estilo de la forma anidada.

Desde luego que hay mucha lógica en lo que dices, pero como mencioné antes:

Empezado por Al González

...El problema de la versión compacta es que no ofrece seguridad para destruir el objeto B. Si la sentencia "A.Free;" eleva una excepción, la rutina se romperá en ese punto y el programa no alcanzará a ejecutar la sentencia "B.Free;", quedando un objeto ocupando memoria inútilmente. En cambio, con la versión anidada, el programa destruirá a cada uno de los objetos instanciados, independientemente de lo que suceda durante el uso de los mismos...

Ante lo cual argumentas que:

Empezado por roman

...entramos en un terreno peliagudo. Hasta donde yo he visto en los grupos de Borland (que es de dónde saqué inicialmente estas cuestiones) es, por el contrario, sumamente raro ver una excepción en un destructor. Uno puede asumir que no habrá excepciones. De lo contrario tendríamos que proteger cada llamada al destructor, incluida la del inherited en la implementación de nuestro propio Destroy...

Razonamiento que también me parece lógico, pero no del todo válido. Es decir, creo que depende de cada situación en particular. En ocasiones podremos asumir que no habrá excepción alguna al liberar un objeto, por realizar su destructor un trabajo relativamente fácil. Pero indudablemente que en otras ocasiones preferiremos la forma anidada por ser indiscutiblemente más segura.

En concreto, creo que siempre estaré inclinado a usar la forma anidada, como lo hizo Borland en esta parte de la unidad AxCtrls.pas de Delphi 7:

Código Delphi [-]
var
  OleStream: TOleStream;
  Writer: TWriter;
begin
  OleStream := TOleStream.Create(Stream);
  try
    Writer := TWriter.Create(OleStream, 4096);
    try
      Writer.IgnoreChildren := True;
      Writer.WriteDescendent(FControl, nil);
    finally
      Writer.Free;
    end;
  finally
    OleStream.Free;
  end;

Aunque probablemente utilice la forma compacta en algunas ocasiones (por confiar en que la primera destrucción no elevará una excepción), como confió Borland en esta parte de la unidad Buttons.pas:

Código Delphi [-]
var
  TmpImage, DDB, MonoBmp: TBitmap;
  ...
begin
  ...
          MonoBmp := nil;
          DDB := nil;
          try
            MonoBmp := TBitmap.Create;
            DDB := TBitmap.Create;
            ...
          finally
            DDB.Free;
            MonoBmp.Free;
          end;

Pero además, si para algunas situaciones se vale asumir que un destructor no elevará excepción alguna, entonces el mismo criterio podría ser aplicado a un constructor, como lo hizo Borland en esta parte de ComCtrls.pas:

Código Delphi [-]
var
  ...
  LSelect, LDeselect: TList;
  ...
begin
  ...
    LSelect := TList.Create;
    LDeselect := TList.Create;
    try
      ...
    finally
      LDeselect.Free;
      LSelect.Free;
    end;

En conclusión, hay tres formas de hacerlo:
1. Anidada con un Try-Finally por instanciación.
2. Compacta con asignación de Nil antes del Try e instanciaciones dentro del Try.
3. Compacta con las instanciaciones antes del Try.

¿Cuál es la más segura? La 1.

¿Cuál es la más correcta? Depende de cada caso y del criterio aplicado.

Empezado por roman

...surge otra cuestión interesante: Si el constructor de un objeto genera una excepción, el objeto no termina de construirse, pero es muy posible que ya haya asignado recursos, por ejemplo, al invocar al constructor de la clase ancestra:

¿El destructor de la clase ancestra es invcado en automático? ...

Muy buena pregunta, Román. Desde que leí esta parte de la ayuda de Delphi, hace ya muchos años:

Empezado por Borland

...If an exception is raised during execution of a constructor that was invoked on a class reference, the Destroy destructor is automatically called to destroy the unfinished object...

entendí que el destructor al que llama Delphi es al de la misma clase que utilizas para crear la instancia. El cual, se entiende, llama a su vez al destructor de sus clases ancestro.

No sé si tu inquietud va por el lado de que la elevación de una excepción en ese punto debería causar una llamada directa al destructor heredado, pero es más adecuado que llame al destructor de la propia clase usada para la construcción, ya que así se asegura la liberación de cualquier recurso que el constructor haya alcanzado a asignar. Recordemos que al crear una instancia ésta se inicializa en blanco (ceros) antes de ejecutarse el constructor, así que no hay problema de que el destructor intente algunas liberaciones al estilo "FX.Free" con campos que nunca alcanzaron a tomar un recurso asignado.

Muy interesantes planteamientos, Román.

Saludos.

Al.