try-try-finally-finally
 

Hola,

Varias veces he visto esta construcción:

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

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

¿Por qué no simplemente poner?

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

  { algo de código }

finally
  ObjetoA.Free;
  ObjetoB.Free;
end;

// Saludos

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

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.

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;

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:p:D

Creo que me han dejado en las mismas :D

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 :D

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

Hola,

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

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.

¡Vaya! ¡Qué desastre! :o

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

Hola,

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

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

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

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.


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? :p

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.

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 :D)

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

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? :rolleyes:

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

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

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

Pues no sé David, para mi (y esto obviamente es muy subjetivo) lo esencial era simplemente ver si ante la necesidad de construir dos o más objetos, es posible asegurar la correcta destrucción sin necesidad de un nivel de anidación por cada objeto construido, que me parece muy confuso.

Hasta donde alcanzo a ver, sí es posible, siempre y cuando inicialicemos a nil todas las variables.

// Saludos

Hola disculpen que me meta donde no me llamen, no se si se deba a que estoy un tanto dormido, pero no termino de comprender a lo que se desea llegar.

No conozco demasiado, pero tengo entendido que una máxima de la programación dice "un objeto o se crea o no crea, no puede ser creado a medias". Si ocurre un error durante la creación de un objeto tiene lugar el evento destructor para limpiar la memoria, por tanto quedará la variable quedará apuntando a nil.

Tengo entendido, por favor corrijanme o tirenme de la oreja si me equivoco, que el método create no provoca ninguna excepción por lo que incorporar la sentencia

Código Delphi [-]
ObjA := TObjA.Create;

dentro de un Try está demás. No puede esperarse capturar una excepción en Create, más bien se puede capturar cuando se desea hacer uso de algún método y/o acceder a una propiedad.

De modo que la excepción que obtendremos es ese famoso EAccessViolation. En síntesis, yo lo veo así:

Código Delphi [-]
objA := TObjA.Create;
try
    ObjtA...
    ...
except
    on E: EAccessViolation do
        ShowMessage('¡Hey, Obj no ha sido creado!);
end;

Repito nuevamente, no se si es eso lo que se trata de ver aqui. La verdad es que me sentí un tanto confundido cuando leía este hilo. Mas yo posteo aqui por curiosidad y por un tirón de orejas para ver si logro aprender el tema que se está debatiendo.

Saludos,

Hola, solo una duda

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;

¿porque esta asignación? ¿si falla el create, o incluso si no llega, no estan apuntando A y B a 0x0000 desde el principio?


PD : Vale, ahora lo lei... claro esta que con freemem(A) no harian falta. No, tampoco funciona si que se tiene que asignar.

Pues a mi las dos construcciones que pone roman en el post numero 11 me parecen correctas. Yo escogeria siempre la primera, sobre todo porque estoy mas acostumbrado a hacerlo así, pero ambas son tecnicamente correctas.

Solo aclarar un par de cosas:

• El metodo create de un objeto puede provocar una excepcion (Por ejemplo un TFileStream con un nombre de archivo incorrecto)
• Si el metodo Create provoca una excepcion devuleve nil y el metodo destroy del objeto es llamado automaticamente.

En resumen, si me dan a escoger, yo escojo la primera forma. Pero si tengo que crear 20 objetos juntos no dudaria en usar la segunda forma que expone roman.

Domingo, temo que la primera parte no es así, haz la prueba:

Código Delphi [-]
type
  TObjetoA = class
    constructor Create;
  end;

{ TObjetoA }

constructor TObjetoA.Create;
begin
  raise Exception.Create('Oops!');
end;

...

var
  A: TObjetoA;

begin
  //A := nil;

  try
    A := TObjetoA.Create;
  finally
    A.Free;
  end;
end;

Al menos en Delphi 7, con la línea comentada, la llamada a A.Free genera una violación de acceso, mientras que con la asignación previa a nil no pasa nada.

En resumen, en ese sentido un constructor es como cualquier función; si hay una excepción, la función no devuelve nada y no se puede tomar el valor de retorno.

Creo que esto contesta también a Delphius. El destructor se llama en caso de una excepción, pero no hay asignación implítcita a nil.

// Saludos

Y tienes razon. De la segunda parte estaba seguro, sobre todo porque asi viene en la documentacion de delphi, pero con respecto a lo primero estaba equivocado. No hacen falta pruebas, es completamente logico que si se provoca una excepcion la funcion no devuelva ningun resultado, no se en que estaba pensando :o

¡Hola!

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

Desde luego que hay mucha lógica en lo que dices, pero como mencioné antes:
Ante lo cual argumentas que:
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.

Muy buena pregunta, Román. Desde que leí esta parte de la ayuda de Delphi, hace ya muchos años:
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. :)

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

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

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

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

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

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

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

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.

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

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.

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

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.

Es precisamente lo que he hecho.

Y así lo he hecho.

// Saludos

Bueno, en ese caso creo que ya todo está dicho por nuestra parte y hemos llegado a un consenso, además de haber esclarecido lo que quisimos decir desde los primeros mensajes del hilo.

1. Las tres formas son válidas (la anidada y las dos compactas)
2. Se aconseja hacer una análisis de “riesgo”, aunque sea mínimo, antes de decidir cual forma utilizar.

Muchas gracias Román, aprendí mucho con este hilo Y te pido una sincera disculpa si me mostré algo altanero.

Saludos.

Al. :)

Buenas,
Después de haber dormido bien, me puse a leer con atención este hilo.
Calladito, tranquilo y con la mente en frio pude comprender cada cosa que se ha tratado aqui (al menos hasta lo que mi cerebrito es capaz de asimilar).

Me he dado cuenta de los riesgos que estaban hablando y me he percatado de algo: debo empezar a ser un tanto más analista en los constructores y destructores:o.

Yo hasta el momento no he protegido ningún Create:eek: y he seguido al pie de la letra lo que expuse en el otro post.

Les estoy enormemente agradecido, si no fuera por este hilo tal vez mi comprensión sobre los constructores, destructores y las formas de proteger el código no me hubieran llevado a ponerme más alerta y pudiera haber continuado a escribir código asi por un buen tiempo... al menos hasta llegar a algún código de la VCL como los que ha señalado Al.

Este hilo se va directo para mi biblioteca. Y pasará por la impresora. Lo que se ha dicho aqui es oro, y como bien señalan debe ser tenido muy en cuenta.

Sigo asombrado por el hecho de que yo, que en ocasiones me pongo muy a la defensiva sobre el uso correcto en POO haya estado descuidando algo tan vital como lo es crear y liberar objetos. Creo que cargaré con la ignorancia un buen tiempo; espero que la experiencia y la práctica me lleven a eliminar ese mal de mi poco a poco y poder definitivamente aplicar los criterios adecuados de forma casi intuitiva.

Me han abierto los ojos, y se que me va a costar un poco ir asimilando lo que aquí se ha dicho.

Muchas gracias por abrir este hilo y exponer sus ricas experiencias.
Y de paso, por tirarme de las orejitas:D.

Saludos,

Hola Delphius,

En realidad, no creo que haya que ponerse paranóico al momento de escribir. Nota que aquí se ha tratado una situación en particular, pero en lo general, el esquema tradicional:

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

try
 ...
finally
  A.Free;
end;

es más que suficiente y correcto.

// Saludos

Tal como tu mencionas, en lo general la forma tradicional funciona. Yo hacía referencia a que esas particularidades son con las que debo de llevar el debido análisis. Y esto es así debido a que hace un tiempo tuve uno de esos "dilemas POO" y me condujo a rebuscarle el modo fácil, no necesariamente el más correcto. Me mal acostumbré a generalizar tanto, en que en caso de volver a detectar algún dilema le buscaba la vuelta.

Hacía, y hago de vez en cuando, lo posible para evitar esa situaciones particulares. Este hilo, me hace recordar que generalizar demasiado no es bueno. Sobre todo cuando se presentan situaciones un tanto atípicas a lo normal. Por ello el aprendizaje que debo seguir pasa por prestar un poco más de atención a las situaciones y no tratarlas con un cañón. ¿Si basta con una pistola, para que cargar con el cañón?

Saludos,