FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Una correcta manera de utilizar TFileStream capturando posibles excepciones variadas?
Pues, eso... como dice el título. ¿Cuál es la manera más apropiada de manejar un TFileStream capturando y lanzando las excepciones de forma apropiada?
Actualmente tengo esta chapuza de código:
Creería que el código se explica solo. Básicamente estoy leyendo un archivo matricial y cargando la data. Mi archivo está pensado con una estructura como la siguiente: 1) Viene una especie de identificador de archivo. Para el caso de matrices, tiene un valor y para vectores otro. 2) Seguidamente una cabecera que contiene la información relacionada con la dimensión de la estructura de datos. 3) Los datos propiamente dichos 4) Y por último un identificador de fin de archivo. Este es común para ambos tipos de archivos. Se que puede ser mejorado. Pero ya tengo la cabeza muy hecha trizas, y se me confunden los tantos... Por un lado quisiera poder detectar posibles excepciones que arroje el FFileStream, desde su creación hasta cuando intenta leer y/o escribir y por el otro quisiera poder lanzar las excepciones propias que tengo definidas para el contexto de esta clase que estoy diseñando en base a mis pruebas. ¿Cómo debo proceder? ¿Un doble try anidado? ¿Cómo lo encararían ustedes? Por si ayuda a comprender el código, adjunto la descripción de la clase:
Los métodos MakeHeader() como IsValidFormat() creerían que no hace falta que adjunte. Se pueden hacer una idea de su uso. Básicamente se procede a armar la cabecera de cada archivo, y en los otros de realizar las comprobaciones de formato para asegurarse de que se ha leído un archivo correcto. Leyendo la documentación, durante la creación del TFileStream es posible que se presente una excepción EFOpenError, y también puede presentarse excepciones durante el ReadBuffer y en el WriteBuffer... no dice la documentación cual. Aparentemente, de lo que estoy viendo en el código de la clase TStream parecen ser EReadError y EWriteError respectivamente. Para el guardado de vectores el código sería algo similar. Las versiones Save() estimo que debieran de tener un código análogo, salvando el detalle de aplicar un WriteBuffer. Cualquier ayuda y propuesta se les agradece. De algunas búsquedas que he estado realizano he notado que todos los códigos de ejemplo no protegen la creación del TFileStream dentro de un try, si en cambio asumen un código exitoso y proceden a aplicar un try-finally para asi liberar el TFileStream. Es decir:
Naturalmente, cuando se puede dar garantías de que el modo de apertura o creación del archivo nos permite un código seguro para una lectura o bien de la escritura no hay problemas con el código anterior (o al menos no esperaría algo tan problemático). Sobre todo si uno tiene separado lo que hace escritura de la lectura. Me he estado cuestionando, ¿Y si espero que mis archivos sean de lectura Y escritura? ¿Que acaso no vale la pena proteger la creación del TFileStream? Yo ya estoy medio perdido. Recuerdo la discusión debate que hubo en ClubDdelphi sobre algo relacionado con esto. En él se comentó sobre el caso particular que plantea justamente: para el caso en donde un constructor eleva una excepción. Para ese entonces, el debate no hiló fino en ese caso y se abordó hacia un planteo general. La documentación de Delphi sugiere que un objeto es creado o no creado. Nada de a medias, que se invoca a Destroy implícitamente y no tendría sentido un Free por el lado de Finally. Más me sigo cuestionando, ¿Y que hacemos como excepción? Tu dices que debiera de controlarse efectivamente de que el recurso, en este caso, un archivo esté abierto. Sabemos que entre Delphi y Lazarus tienen sus diferencias. ¿Aquí será un caso? Intenté llegar a algo que me aclare el punto, y llego a algo parecido a la discusión en CD pero para el caso de Lazarus, no hay una confirmación real si FPC se comporta igual que Delphi en esto. La gente que ha intervenido en el mailing list asume que SI. ¿Debiera de proteger con except? ¿con Finally? ¿emplear doble try como se ejemplifica acá? Yo ya estoy confundido. Suelo tener cuidado con los constructores y destructores. Me he valido varias veces del uso de excepciones, pero el emplear el TFileStream y el querer poder tanto capturar posibles excepciones de éste, como de lanzar algunas propias para el contexto de mi clase TConverter y que en última las clases que usen a ésta sepan valerse me ha vuelto a las bases para replantear estas cuestiones. Muchas gracias. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Capturando excepciones en un archivo de texto | noob | Varios | 5 | 20-02-2009 09:47:46 |
Duda sobre posibles excepciones en una desconexión de un socket | noob | Varios | 0 | 13-02-2009 19:33:14 |
TMaskedit, con posibles excepciones en el formato | grotero76 | OOP | 6 | 31-01-2008 13:49:23 |
Cómo utilizar consultas con DISTINCT de forma correcta | dec | MySQL | 9 | 19-09-2006 17:50:47 |
lista de todas las posibles excepciones | maruenda | Varios | 1 | 06-12-2004 22:31:02 |
|