try-try-finally-finally

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

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

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

    { algo de código }

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

Y yo estaba equivocado. Puesto así, el compilador no genera ningún warning.

// Saludos

[[cHackAll]]

Esperando no complicar mas las ideas voy aclarando algunas dudas; try crea una instruccion de "salto en caso de error", obviamente "salta" a la primera instruccion de su respectivo finally ejecutando su contenido hasta end; cada try genera un salto distinto para permitir al desarrollador un control más especifico para cada posible error, por ello desde el punto de vista de compilación los casos anidado y "compacto" generan un codigo binario distinto.

Si la excepción es generada dentro del constructor, el valor retornado por el mismo es nulo (puesto que falló durante la creación de la nueva instancia), por ende, el llamado al método en memoria 0.Destroy ó 0.Free generan el mismo error de acceso a una zona de memoria vacía.

Código Delphi [-]
uses SysUtils; {$apptype console}
 
var Saved: procedure;
 
procedure OnExit;
begin
 ReadLn; // antes que la consola se cierre por la excepción, 
            // esperaremos a que el usuario vea los mensajes y pulse {ENTER}
 Saved;
end;
 
type
 TThrow = class // (TObject), clase base...
  procedure Throw;
  constructor Create;
  destructor Destroy; override;
 end;
 
procedure TThrow.Throw; asm dd 0F4F6E432h end; // provocamos una división por cero.
 
constructor TThrow.Create;
begin
 inherited;
 WriteLn(Self.ClassName + '();'); // mostramos un mensaje para notificar que el constructor hizo su gracia.
end;
 
destructor TThrow.Destroy;
begin
 WriteLn('~' + Self.ClassName + '();'); // para notificar que el destructor hizo lo suyo.
 inherited;
end;
 
type
 TFirst = class(TThrow); // heredamos...
 TSecond = class(TThrow);
 
var
 a, b: TThrow;
 
begin
 @Saved := ExitProc;
 ExitProc := @OnExit;

 {$define anidado} // Comenta esta línea para probar un try..finally NO anidado.

 {$ifdef anidado}
 try
  a := TFirst.Create;
  // ...
  a.Throw;
  // ...
  try
   b := TSecond.Create;
   // ...
   b.Throw;
   // ...
  finally
   b.Destroy;
  end;
 finally
  a.Destroy;
 end;
 {$else}
 try
  a := TFirst.Create;
  // ...
  a.Throw;
  // ...
  b := TSecond.Create;
  // ...
  b.Throw;
  // ...
 finally
  a.Destroy;
  b.Destroy; // aquí el detalle... aún no ha sido construido "b", generamos una nueva excepción
 end;
 {$endif}
end.

En el anterior ejemplo he "sacado" la generación de la excepción del constructor, para demostrar que entre el codigo inicial de Roman y último no es relevante la construcción del objeto, si no el orden construcción/excepción de los objetos.

En el caso anidado el control es mayor y más estructurado, como resultado obtenemos un EDivByZero que era justamente lo esperado... lo que difiere al comentar la directiva de precompilación, " // {$define anidado}" obteniendo un EAccessViolation al intentar destruir un objeto "inexistente".

Podriamos hacer otro ejemplo no OO, talvez ordenes de apertura y cerrado de archivos de paginación... en tal caso obtendriamos un resultado que al igual que en el ejemplo depende de la estructura del codigo.

Saludos