|
Hola Al.
Te agradezco tu aporte.
De lo que veo en tu propuesta, aplicas un triple try anidado y separas la excepción de la creación del FileStream de las excepciones que puede arrojar un Read o Write, y dejas a un try-finally intermedio cuando se dan situaciones "segura" y por tanto proceder a finalizar el Free.
No se diferencia mucho de la 2da propuesta que logré diseñar. Basicamente la diferencia radica en donde capturar y lanzar las excepciones propias.
Ayer estuve haciendo más pruebas y pude apreciar que no necesito relanzar la excepción como me estaba preguntando ¡Lo hace! Mi miedo era que el raise de EInvalidFileArrayFormat y/o el de EInconsistArray fuera capturado por el except y no se mostrara dicha excepción y tuviera que añadirla en la lista y volver a aplicar un rise. La excepción "pasa de largo" y efectivamente se termina recibiendo desde el "lado cliente".
Aparentemente todo funciona bien. La aplicación de prueba me ha permitido evaluar las alternativas, y en ciertos casos forzando algunas situaciones como un fallo de lectura/escritura. Se detectan las excepciones y se lanzan las adecuadas.
Tendría que probar tu alternativa, pero tengo que continuar con el trabajo. Por el momento tengo en suspenso tu propuesta. Y será el camino hacia una nueva versión si lo amerita, o bien en cuanto pueda disponer de tiempo y se justifique algo más seguro.
CheckMatrix no ha sido diseñada para lanzar excepciones. Pertenece a una unidad (que junto a otras forman un gran módulo) que contiene cientos de procedimientos y funciones dedicadas a álgebra lineal y otras cosas más. Su diseño, a la vieja escuela (paradigma estructurado), no ameritaba algo OO por lo que CheckMatrix, por ejemplo, se limita a ofrecer variables de control como ser el código de error generado y adicionalmente la dimensión de la matriz.
Es una unidad que ya ha alcanzado un grado de madurez bastante elevado y tiene casi 3000 líneas de código. No se malgasta en clases, excepciones, va a lo directo. Su diseño a sido dual: ofrece procedimientos bajo situaciones ideales, y además ofrece funciones y otros métodos de evaluación y control para aquellos casos en los que se necesita ciertas evaluaciones previas.
Las clases/módulos clientes de esta gran biblioteca si quieren pueden seguir el diseño estructurado o bien, aprovechar el poder OO para situaciones más complejas.
Los mensajes de algunas excepciones, si te fijas en mi 2da propuesta, aplican a un Format() a un string. Entre los parámetros paso el mensaje de la excepción original. De este modo el texto de la excepción que arrojo lleva consigo no sólo el texto para el contexto esperado (el Converter) sino además información adicional que provee sobre el TFileStream (aunque el texto de éstas más bien es básico según lo que vi en su código).
Lo de escribir en un único idioma, si es que te lo preguntas el porque uso comentarios en español y código en inglés, es porque ya me acostumbré asi. La idea es que los comentarios me ayuden a entender lo que tengo y para ello recurro al español. Después de todo es trabajo personal.
Lo que evitar algoritmos de más de 20 líneas lo tengo presente. Pero en ocasiones debemos extendernos más. Tengo por ejemplo en otra unidad un procedimiento que tiene 130 líneas de código. Se podría particionarlo, pero ya de por sí las operaciones se hacen de manera óptima y goza de buena velocidad. De particionarlo, algunas partes se estarían llamando cientos de veces. Preferí centrar todo y se ejecute en un único procedimiento antes que estar lidiando con las vueltas de código repartido en varios.
Te agradezco tu ayuda porque siempre se aprende algo nuevo. Seguro que esta lección del triple-try la pongo en práctica para otro caso, que tiene cierta semejanza con el TArrayConverter. Es otra especie de conversor pero para otras clases (quizá más manejables que el TFileStream... espero) y finalidades.
Seguramente nos mantendremos en contacto.
Saludos,
|