FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Bloques Try-Finally para proteger múltiples recursos en Delphi (Traducción)
Entrada original (En ingés)
El lenguaje Delphi comparte con muchos otros un patrón de asignación de recursos estándar para garantizar que, en el caso de una excepción, los recursos se liberen de forma adecuada. Los recursos en este contexto son objetos de memoria, archivos, objetos y manejadores del sistema operativo, y similares. En Delphi, en comparación con otros lenguajes con un recolector de basura, la relevancia aumentó por consideraciones de administración de memoria. Protegiendo un solo objeto En los casos más simples, escribirías código como:
Un ejemplo más específico sería como:
Hasta aquí todo bien. Tenga en cuenta que si se produce un error durante la ejecución del constructor, Delphi ejecutará automáticamente el destructor para el objeto parcialmente inicializado (pero este podría ser un tema para otra publicación de blog). Protección de dos objetos: cómo NO escribir el código El problema en el que me quiero enfocar es cómo escribir el mismo tipo de código si necesita asignar y eliminar dos recursos. Aquí hay múltiples opciones. Lo que no debes hacer (pero es bastante común) es escribir:
El problema con este código es que, en caso de que falle la creación de A2 (y podría haber muchas razones), el objeto A1 permanecería en la memoria. Y simplemente colocar la segunda asignación dentro del bloque TRY tampoco es bueno:
Con este código en caso de una falla en la llamada al constructor del objeto A2, el bloque finally intentará liberar un objeto no inicializado (el valor predeterminado de una referencia de objeto local no está definido). Esta es la razón por la cual una posible solución es establecer A2 a cero al comienzo, ya que llamar Free en un objeto nulo no tiene ningún efecto. O configurar todas las referencias de objetos como nulas para simplificar y uniformizar. O escriba dos bloques try anidados para proteger cada uno de los recursos. Protección de dos objetos: una historia de tres soluciones Esta larga introducción nos lleva al punto de esta publicación de blog. Hay al menos 3 soluciones correctas diferentes para la protección de dos recursos en el mismo bloque de código, como acabo de mencionar. Estas son las tres soluciones que "tomé prestada" de uno de nuestros arquitectos de RAD Studio R & D, Bruneau Babet. #1
#2
#3
Siempre que todos sean correctos en términos de gestión de recursos adecuada en todos los escenarios, ¿cuáles son las ventajas y desventajas de estas 3 soluciones? Lo que es importante considerar es que los 2 recursos podrían ser 3, o 4 o media docena. ¿Cuál elegir? La primera solución con los bloques de intentos anidados es bastante limpia pero más detallada (más líneas de código) y tiene anidamiento adicional que podría convertirse en una molestia con múltiples recursos. Además, hay un costo de tiempo de ejecución asociado con los bloques try, claramente limitado pero no cero. La segunda solución tiene la menor cantidad de líneas de código y la menor cantidad de tiempo de ejecución. El único adicional es configurar A2 a nil. El código sigue siendo legible también con muchos recursos. Sin embargo, el código es "desequilibrado" y podría ser un poco confuso. La tercera solución va en la misma dirección, pero agrega una asignación adicional técnicamente inútil a nil (para A1), ofreciendo la ventaja de ser más limpio y más equilibrado, y probablemente más legible después de todo. Entonces, ¿cuál es la mejor solución? Esto es realmente difícil de decir. Personalmente usé principalmente el número 1 en mis libros, pero en Embarcadero tendemos a preferir los más limpios y más rápidos (es decir, los n. ° 2 o n. ° 3) para el código de la biblioteca
__________________
Buena caza y buen remar... http://mivaler.blogspot.com |
#2
|
||||
|
||||
Alguna vez discutimos esto por aquí. Yo uso (o usaba) la tercera opción desde que la vi mencionada -no recuerdo si por Marco Cantú o por Peter Below. Me parece la más limpia y simétrica. La versión anidada es horrible ya que habría que agregar una anidación por cada objeto.
No obstante, hay quienes objetan la tercera opción (me acuerdo de Al González) ya que el destructor de A2 podría causar una excepción y dejar A1 sin liberar. Pero, como decía el mismo Cantú o Below, un destructor no debe nunca, pero NUNCA, causar una excepción. Y si la causa significa un mal diseño que hay que corregir antes que preocuparse por A1. LinneComment Saludos |
#3
|
||||
|
||||
#4
|
||||
|
||||
Eso de buscarse a uno mismo en Google tiene sus sorpresas, je-je-je.
¡Un gran saludo, Román! |
#5
|
|||
|
|||
Hola... yo siempre uso el metodo 3, pero asegurando mas el finally
Código:
var A1, A2: TTest; begin A2 := nil; A1 := nil; try A1 := TTest.Create; A2 := TTest.Create; //Use A1 and A2 finally if Assigned(A2) then FreeAndNil(A2); if Assigned(A1) then FreeAndNil(A1); end; end |
#6
|
||||
|
||||
Tu solución, fremen, es redundante (que no mala). Lo digo porque ya el método "Free" comprueba si el objeto existe (hay un "IF Self <> Nil", si no recuerdo mal), al igual que en FreeAndNil. Eso sí, el uso de FreeAndNil me gusta, y yo lo uso bastante, aunque no suelo poner el "IF Assigned" delante.
|
#7
|
||||
|
||||
Yo creo que lo mas pragmatico es tener constructores y destructores simples (por lo general yo no redefino destructores). Si se tienen constructores simples que lo unico que hacen es asignar los valores que reciben, pero no crean objetos, entonces la forma #3 es totalmente segura
Con esto me refiero a que, en lugar de que un objeto cree un descendiente de TStream (lo cual puede tener complicaciones), mejor que lo reciba ya correctamente inicializado; de este modo, el no tendra que tambien ser responsable de saber como crear el stream, que hacer si no se puede crear, ni responsable de destruirlo |
#8
|
|||
|
|||
Cita:
El porque del FreeAndNil. Código:
var A1, A2: TTest; begin A2 := nil; A1 := nil; try A1 := TTest.Create; A2 := TTest.Create; //Use A1 and A2 finally if Assigned(A2) then FreeAndNil(A2); A1.Free; end; // Aquí A2 siempre es Nil. Así, si tengo un descuido tal que... A2.Propiedad_X := 1; // Genera excepción siempre y en el periodo de pruebas lo detecto a la primera // Aquí A1 tiene un valor indeterminado. A1.Propiedad_X := 1; // Según el estado de la memoria que apunte A1, unas veces generara excepción y otras no. Resultado: Errores aleatorios end; Código:
procedure FreeAndNil(var Obj); {$IF not Defined(AUTOREFCOUNT)} var Temp: TObject; begin Temp := TObject(Obj); Pointer(Obj) := nil; => Error Temp.Free; end; {$ELSE} begin TObject(Obj) := nil; => Error end; {$ENDIF} |
#9
|
|||
|
|||
Cita:
|
#10
|
||||
|
||||
Cita:
|
#11
|
|||
|
|||
Cita:
Aunque veo sus ventajas a este patrón, a mi personalmente no me convence. Pero para gustos, colores. Y otra cosa no, pero colores en programación tenemos cientos... |
#12
|
||||
|
||||
Este caso raro es más bien un caso erróneo: estás haciendo referencia a tus objetos A1 y A2 fuera del bloque try-except que está justamente para protegerlos. Además, la sección finally se usa para liberar los objetos por lo que es un error querer usarlos fuera de esa cláusula.
LineComment Saludos |
#13
|
|||
|
|||
Cita:
|
#14
|
||||
|
||||
Es que no es la forma de hacerlo. No necesitas "cazar un error" que tú mismo estás provocando. Simplemente no provoques ese error.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Recursos en Español para delphi 6 | GerTorresM | Varios | 2 | 04-01-2010 16:11:16 |
Ayuda para completar código:Traducción de Delphi a Builder | Pernorak | C++ Builder | 3 | 30-05-2007 13:45:16 |
Traduccion de recursos (VCL) | arm | Varios | 0 | 22-09-2004 14:11:09 |
Recursos en castellano para Delphi 7 | xerkan | Varios | 1 | 05-03-2004 10:27:42 |
|