try-try-finally-finally

[dec]

Hola,

Creo que alguna vez escribí código como el que copias arriba. No sé. El asunto parece más o menos lógico, pero, seguramente habría que pensar las cosas mejor, y ver si realmente, igual incluso convendría hacerlo como dices Román. Hum...

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

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