try-try-finally-finally

[roman]

Empezado por 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?

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

[[Delphius]]

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,

[[coso]]

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.

[[seoane]]

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.

[roman]

Empezado por seoane

• Si el metodo Create provoca una excepcion devuleve nil y el metodo destroy del objeto es llamado automaticamente.

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

[[seoane]]

Empezado por roman

Domingo, temo que la primera parte no es así

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