try-try-finally-finally

[[seoane]]

Es una rutina: crear objeto, try ... finally y destruir el objeto. Es algo que ya se hace casi sin pensar, como poner un begin ... end. Además a mi me parece que el código queda mas estructurado, mas fácil de leer y modificar. De todas formas supongo que el compilador, después de optimizar un poco, generara un ejecutable muy parecido.

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

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