try-try-finally-finally

[[eduarcol]]

la unica logica que le veo a esa estructura es que hubiese codigo entre los dos finally:

Código Delphi [-]
try
  ObjetoA := TObjectoA.Create;
  
  try
    ObjetoB := TObjetoB.Create;
    
    { algo de código }

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

[[Caral]]

Hola
Metiendome donde no me llaman diria que se crea un objeto y si este esta creado entonces se crea el segundo objeto.
Yo lo entendería así:

Código Delphi [-]
try
      ObjetoA := TObjectoA.Create;
      if ObjetoA.Create then
      try
      ObjetoB := TObjetoB.Create;
      { algo de código }
      finally
      ObjetoB.Free;
      end;
finally
  ObjetoA.Free;
end;

Se supone que el primer objeto se creo, pero tal vez fallo algo, no se.
Interesante.
Saludos

[[BlueSteel]]

Empezado por Caral

Hola
Metiendome donde no me llaman diria que se crea un objeto y si este esta creado entonces se crea el segundo objeto.
Yo lo entendería así:

Código Delphi [-]try ObjetoA := TObjectoA.Create; if ObjetoA.Create then try ObjetoB := TObjetoB.Create; { algo de código } finally ObjetoB.Free; end; finally ObjetoA.Free; end;

Se supone que el primer objeto se creo, pero tal vez fallo algo, no se.
Interesante.
Saludos

yo concuerdo con Caral, puede ser que para crear el 2do objeto sea necesario que el primero exista.....

No es lo mismo crear 2 objetos, que crear 2 objetos pero que uno dependa del otro... es decir para llegar al objeto 2 debo pasar obligatoriamente por 1... de lo contrario no procede...

Salu2

[roman]

Creo que me han dejado en las mismas

A ver. En lo personal, se me hace más clara la segunda forma ya que entre más anidación, menos claridad. La pregunta es si ambas formas son equivalentes.

Creo recordar haber visto esta cuestión en alguna parte anteriormente. En la segunda forma, la compacta, si hay un error durante la creación del objeto A, el código del finally se ejecutará indistintamente, lo cual incluye la llamada al método Free de ObjetoB, y esto podría ser un problema, si la variable ObjetoB no está inicializada -según recuerdo, las variables locales no necesariamente se inicializan en automático, así que ObjetoB podría no ser nil.

Entonces, podríamos poner

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

antes de la creación de los objetos (Free sirve aún si la referencia es nil). Pero el condenado compilador insiste en lanzarnos un warning, lo cual, si bien no daña si molesta

Por otra parte, aún en una construcción simple:

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

  { algo de código }

finally
  ObjetoA.Free;
end;

¿qué pasa si el constructor de A provoca una excepción? ¿Puede garantizarse que la llamada a ObjetoA.Free no causará una violación de acceso?

// Saludos

[dec]

Hola,

Empezado por Román

¿qué pasa si el constructor de A provoca una excepción? ¿Puede garantizarse que la llamada a ObjetoA.Free no causará una violación de acceso?

Lo primero que se me viene a la cabeza es que en caso de excepción se entra en un modo en que las cosas funcionan de otra manera... Vale. Sé que esto igual no tiene mucho sentido, porque además no explico nada de nada. No tengo sino la poca práctica de "ver excepciones" no seguidas de "violación de acceso" alguno, en código similar al que muestras arriba Román.

PD. Por otro lado, estamos usando el método "Free()", que se supone que ofrece cierta seguridad, no como el método "Destroy()", según tengo entendido, que sí que podría causar algún que otro problema.

[roman]

¡Vaya! ¡Qué desastre!

Desde el principio, he puesto mal el código. Debería ser:

Forma 1:

Código Delphi [-]
ObjetoA := TObjectoA.Create;

try
  ObjetoB := TObjetoB.Create;

  try
    
    { algo de código }

  finally
    ObjetoB.Free;
  end;
finally
  ObjetoA.Free;
end;

Forma 2:

Código Delphi [-]
ObjetoA := TObjetoA.Create;
ObjetoB := TObjetoB.Create;

try

  { algo de código }

finally
  ObjetoA.Free;
  ObjetoB.Free;
end;

Espero disculpen

// Saludos

[dec]

Hola,

Creo que todos hemos visto bien lo que en realidad estaba mal, porque, enseguida hemos ido a la "idea" del asunto, al "conceto".

[[Al González]]

Empezado por roman

...En la segunda forma, la compacta, si hay un error durante la creación del objeto A, el código del finally se ejecutará indistintamente, lo cual incluye la llamada al método Free de ObjetoB, y esto podría ser un problema, si la variable ObjetoB no está inicializada -según recuerdo, las variables locales no necesariamente se inicializan en automático, así que ObjetoB podría no ser nil...

Y también aunque se tratara de una variable global, ya que ObjetoB podría tener el vestigio (la dirección de memoria) de una instancia que previamente le fue asignada y luego destruida. De ahí que en algunos casos se recomiende el uso de FreeAndNil.

Empezado por roman

Y bueno, al parecer las formas realmente equivalentes son estas:

Forma anidada:

Código Delphi [-]
 
var
  A: TObjetoA;
  B: TObjetoB;
begin
  A := TObjetoA.Create;
 
  try
    B := TObjetoB.Create;
 
    try
 
      { algo de código }
 
    finally
      B.Free;
    end;
  finally
    A.Free;
  end;
end;

Forma compacta:

Código Delphi [-]
 
var
  A: TObjetoA;
  B: TObjetoB;
 
begin
  A := nil;
  B := nil;
  A := TObjetoA.Create;
  B := TObjetoB.Create;

  try
    // esto lo moví arriba del Try.  Al.
{    A := TObjetoA.Create;
    B := TObjetoB.Create;}
 
    { algo de código }
 
  finally
    A.Free;
    B.Free;
  end;
end;

...así, el compilador no genera ningún warning [advertencia]...

Eso te iba a comentar, Román, tras leer el primer mensaje del hilo. El "cierre" que se hace dentro de un Finally debe corresponder a la "apertura" hecha justo (o casi justo) antes del Try.

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

Oye Román, ¿no será que Embarcadero te encargó reclutar programadores planteando estas cuestiones tan interesantes?

Saludos.

Al González.

EDITO: Román: Me tomé la libertad de cambiar algo en el código del texto donde te cito, ya que al parecer no estaba corregido del todo. Asumo que en realidad lo querías escribir como ahora lo he dejado.

[roman]

cHackAll, creo que olvidas dos puntos importantes.

Primero, que las inicializaciones a nil en el caso compacto, son esenciales, y segundo, que se recomienda usar Free en lugar de Destroy precisamente porque nil.Free no produce una violación de acceso tal como sí lo hace nil.Destroy.

Haciéndolo así, evitas justamente la nueva excepción que mencionas en tu caso compacto.

Pero por otra parte, hay que notar que la (posible) diferencia entre el caso anidado y el compacto, en los casos que se describen, radica -justamente- en una eventual excepción dentro de un constructor, por lo que no veo el por qué de "sacar" la excepción del constructor.

Vamos a ver si lo aclaramos.

En ambos casos, el objetivo es no dejar ningún objeto sin destruir. El caso anidado es claro que lo cumple por el argumento que esgrime seoane (a fin de cuentas, tiene que ser cierto, o nos han mentido todos estos años )

Veamos el caso compacto, tal como lo escribí luego de corregirme a mi mismo:

Código Delphi [-]
var
  A: TObjetoA;
  B: TObjetoB;

begin
  A := nil;
  B := nil;

  try
    A := TObjetoA.Create;
    B := TObjetoB.Create;

    { algo de código }

  finally
    A.Free;
    B.Free;
  end;
end;

Por supuesto que en la parte que dice

Código Delphi [-]
{ algo de codigo }

puede ocurrir cualquier cosa, pero para entonces ya ambos objetos, A y B han sido construidos exitosamente, de manera que ambos son referencias válidas. Si en el resto de código ocurre algo, el finally se ejecutará sí o sí, asegurando la destrucción de ambos objetos.

Por ellos es que el problema en sí, se da cuando uno de los constructores presente una excepción; si "sacamos" la excepción del constructor, estamos en el caso recién descrito.

Si el constructor de A genera una excepción, la línea

Código Delphi [-]
B := TObjetoB.Create;

nunca se ejecutará, de manera que ni A ni B serán referencias válidas. ¿No?

Incorrecto, porque ambas son nil desde un principio por lo que las llamadas a Free no provocan ningún nuevo error.

Si A se construye exitosamente y el constructor de B genera una excepción, estamos igual de seguros. A.Free no tiene problemas, pero tampoco B.Free pues B se inicializó a nil y Free puede usarse en ese caso.

// Saludos

[dec]

Hola,

Tal vez es que estamos poniendo demasiado énfasis en la liberación de los objetos, cuando quizá el "finally" podría ser también aprovechado para otras cuestiones. Por tanto, no es que nos interese llegar a "finally" con el objeto "válido" o "nil", sino válido en todo caso, puesto que no podremos hacer lo que acaso necesitemos, además de liberar el objeto. En definitiva, igual es que resulta complicado una especie de "plantilla" sobre cómo actuar, sino que dependerá de la situación, ¿no?

[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