try-try-finally-finally

[roman]

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

Si lees lo que comenté a Javier, verás que el problema real radica en las excepciones que se generan en el constructor. Al mover la construcción de los objetos fuera del bloque try-finally-end, impides, por ejemplo, la liberación de A en caso de una excepción en el constructor de B.

Cuando sólo estamos interesados en un objeto, el esquema usual:

Código Delphi [-]
A := TObjetoA.Create;

try
  { algo de código }
finally
  A.Free;
end;

es totalmente válido, pues, si A.Create genera una excepción, no hay, de hecho, ninguna asignación y, por ende, ninguna necesidad de llamar a Free (*).

Pero nota, de hecho, que este esquema es equivalente a:

Código Delphi [-]
A := nil;

try
  A := TObjetoA.Create;

  { algo de código }
finally
  A.Free;
end;

Aunque aquí, la llamada a A.Free (protegida por la inicialización a nil) es innecesaria (A nunca se construye). Pero es este esquema el que nos serviría en el caso de más objetos si deseamos evitar las anidaciones.

Ahora, en cuanto a

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 (como sabes, también al destruir objetos suelen ocurrir excepciones), 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

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:

Código Delphi [-]
destructor TObjetoA.Destroy;
begin
  try
    { código destructor que posiblemente genere una excepción }
  finally
    inherited
  end;
end;

Sin esa protección, el destructor de la clase ancestra no se ejecutaría. Por ello es que un destructor no o no debe producir una excepción.

(*) No obstante, aquí 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:

Código Delphi [-]
constructor TObjetoA.Create;
begin
  inherited;

  { código que posiblemente genere una excepción }
end;

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

// Saludos

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

[roman]

Empezado por Al González

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.

De hecho, la forma que he expuesto ya varias veces, con las líneas donde deben ir, es igual de segura y válida. Si vuelves a leer, verás que las asignaciones a nil se hacen en un lugar preciso y no al azar o por un mero deseo de escribirlo de una u otra forma. Los ejemplos que muestras del código de VCL ejemplifican, de hecho, la validez de ambas opciones.

Cuando se dice: es raro que un destructor genere una excepción, no es sólo que sea algo difícil porque lo que ahí se hace es muy fácil. Es que, como ya mencioné, si un destructor genera una excepción, el objeto no se destruirá correctamente, y es un error -muy grave- que habría que corregir antes siquiera de preocuparse por que el objeto siguiente no se destruya.

// Saludos

[[Al González]]

Las tres formas son válidas, Román, dependiendo de cada caso y criterio. Como ya lo expuse.

No dije que la forma compacta fuera categóricamente inválida. Creo que en este punto de la discusión sería prudente invitarnos a aceptar que las tres formas son válidas, pero cada una dependiendo del contexto, como mencioné antes. Los tres ejemplos que puse ejemplifican que Borland así lo ha concluido también, y creo que pueden servir, junto con el resto del hilo, como una buena referencia para otros compañeros del club.

Un abrazo.

Al.

[roman]

De hecho, yo sé que ambas son válidas desde el mensaje 11. Y, en verdad, no creo que dependa de ningún contexto, sino del gusto de cada quien. Y lo enfatizo porque creo que esto es lo que puede servir de guía a futuro. De lo contrario, habrá que especificar con detalles en qué consiste cada contexto para saber cuándo es aplicable una u otra forma.

// Saludos

[[Al González]]

Empezado por roman

...De hecho, yo sé que ambas son válidas desde el mensaje 11. Y, en verdad, no creo que dependa de ningún contexto, sino del gusto de cada quien. Y lo enfatizo porque creo que esto es lo que puede servir de guía a futuro. De lo contrario, habrá que especificar con detalles en qué consiste cada contexto para saber cuándo es aplicable una u otra forma.

// Saludos

Lo siento, creo que debí decir "Sabemos que ambas opciones son válidas...".

A mí me preocupa que la técnica de programación se base en el gusto personal sin antes analizar el riesgo de funcionamiento del código. El contexto consiste básicamente en advertir si una llamada a un constructor o a un destructor es susceptible de elevar una excepción. El problema con este criterio es que no permite el establecimiento de una regla clara general (casi siempre que las reglas no son claras, el gusto personal asecha).

Sin embargo, puede uno hacer el ejercicio en cada caso, entendiendo grosso modo lo que un constructor o un destructor hace por dentro para decidir si es adecuado darle un nivel de protección "particular" o agruparlo junto con otros, como en los ejemplos que se han expuesto.

No es igual con un constructor que sólo reserva memoria que con uno que abre una conexión de base de datos. O con un destructor que solamente libera memoria que con uno que intenta agregar una línea a un archivo .log, por mencionar un par de ejemplos.

Entiendo que en el caso de los destructores el código debe ser sumamente cuidadoso, pero en la práctica solemos ver cadenas de llamadas a partir de un destructor que desembocan en una rutina lejana que, no pensada para ser llamada durante la ejecución de un destructor, eleva una excepción.

Creo que el gusto o estilo debería ir después de analizar este tipo de vicisitudes, y ante el "empate", entonces sí aplicar el gusto. Pero no precipitarse por lo que más agrada sin un análisis previo, quizá no concienzudo, pero sí realizado cuando menos.

Saludos.

Al.

[roman]

Empezado por Al González

A mí me preocupa que la técnica de programación se base en el gusto personal sin antes analizar el riesgo de funcionamiento del código.

Lamento que interpretes así a la ligera mis palabras. En ningún momento he dicho que cada quien programe como quiera sin importar que esté bien o mal.

Empezado por Al González

El contexto consiste básicamente en advertir si una llamada a un constructor o a un destructor es susceptible de elevar una excepción.

En el caso de constructores esto sería virtualmente imposible. Por ello -precisamente- existen los bloques de protección.

Empezado por Al González

No es igual con un constructor que sólo reserva memoria que con uno que abre una conexión de base de datos.

Es, de hecho, lo mismo. Cualquier reserva de memoria, aunque parezca una operación sencilla, debe estar protegida. Muy lejos del control del programador está el que haya memoria suficiente.

Empezado por Al González

O con un destructor que solamente libera memoria que con uno que intenta agregar una línea a un archivo .log, por mencionar un par de ejemplos.

Intentar acceder a disco es un ejemplo de lo que NO debe hacerse en un destructor.

Empezado por Al González

Entiendo que en el caso de los destructores el código debe ser sumamente cuidadoso, pero en la práctica solemos ver cadenas de llamadas a partir de un destructor que desembocan en una rutina lejana que, no pensada para ser llamada durante la ejecución de un destructor, eleva una excepción.

Como ya he mencionado varias veces, esto en la práctica no sucede, a no ser que estemos trabajando con código sumamente mal diseñado.

Empezado por Al González

Creo que el gusto o estilo debería ir después de analizar este tipo de vicisitudes, y ante el "empate", entonces sí aplicar el gusto.

Es precisamente lo que he hecho.

Empezado por Al González

Pero no precipitarse por lo que más agrada sin un análisis previo, quizá no concienzudo, pero sí realizado cuando menos.

Y así lo he hecho.

// Saludos

[[Caral]]

Hola

Empezado por Al González

.... y creo que pueden servir, junto con el resto del hilo, como una buena referencia para otros compañeros del club.

Y yo agregaría que nos habéis dado una cátedra que hace tiempo no veía en el club.
Ojala se repitan dudas como esta en donde los maestros exponen sus criterios y los Novatos miran, callan y aprenden.
Gracias Señores.
Saludos

[[Al González]]

Empezado por Caral

Hola

Y yo agregaría que nos habéis dado una cátedra que hace tiempo no veía en el club.
Ojala se repitan dudas como esta en donde los maestros exponen sus criterios y los Novatos miran, callan y aprenden.
Gracias Señores.
Saludos

Bueno, yo no me considero ningún maestro, pero que bueno que valores así este hilo. Y eso de que se repitan, pues siempre y cuando haya desayuno previo porque aquí ya va a ser la 1 PM y todavía sigo escribiendo.

No coincido para nada en eso de que los "novatos callen". Al contrario, creo que el hilo debería nutrirse con las opiniones y dudas que otros compañeros tengan, independientemente de la experiencia.

Un abrazo apetitoso.

Al.