try-try-finally-finally

[[Al González]]

Empezado por roman

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

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.

[roman]

Empezado por Al González

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.

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.

Empezado por Al González

El contexto consiste básicamente en advertir si una llamada a un constructor o a un destructor es susceptible de elevar una excepción.

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

Empezado por Al González

No es igual con un constructor que sólo reserva memoria que con uno que abre una conexión de base de datos.

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.

Empezado por Al González

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.

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

Empezado por Al González

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.

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.

Empezado por Al González

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.

Es precisamente lo que he hecho.

Empezado por Al González

Pero no precipitarse por lo que más agrada sin un análisis previo, quizá no concienzudo, pero sí realizado cuando menos.

Y así lo he hecho.

// Saludos

[[Al González]]

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.

[[Delphius]]

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.

Yo hasta el momento no he protegido ningún Create 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.

Saludos,

[roman]

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

[[Delphius]]

Empezado por roman

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,