|
Mamx, el punto es que ahora tu diseño del LoadMatrix() hace que la clase supervisora de TArrayConverter necesite de mayor decisión sobre el estado del archivo y quien deba darle las garantías a su subordinada.
Lo que sugieres es pasar la pelota más arriba y dejar a los "supervisores" a que hagan más trabajo, cuando la idea es justamente que cuando una clase delega algo a otra esta responda bien. Llevado al extremo tendrás clases que no saben delegar nada.
Para este caso la clase TArrayConverter dice, che mirá tengo este error pero te lo dejo a vos y arreglatelas... a mi o me das las cosas masticadas o no te hago nada. Es más el tipo de excepción que se está propagando es algo que no debiera de esperar la(s) clase(s) supervisora(s), sino de algo más interno y que le compete al TArrayConverter. TClaseSupervisora (por darle un nombre abstracto) no debe ni tiene porqué saber que TArrayConverter utiliza TFileStream ni debiera estar lidiando con situaciones de error relacionadas con ésta ni de temas de archivos. ¡Para eso está TArrayConverter!
Por ello es importante capturar estas situaciones cuando se trabaja con archivos. Es muy necesario alertar si se tiene o no acceso a tal recurso. Estas situaciones se pueden dar en dos momentos: 1) al intentar crear dicha clase y acceder al archivo. 2. O bien, al momento de escribir o leer de él.
La situación 2 podemos controlarlo, con el típico diseño try/except. Más el caso patológico es el 1. Lo cual invalida el uso de una instancia de la clase TFileStream y por consiguiente no puede tener lugar el caso 2.
Por todo esto cualquier clase que haga uso de TFileStream debiera de poder controlar ambas situaciones y ofrecer un diseño que responda a esto y no estar relegandole más funciones a su clase cliente (la que tu llamas supervisora).
Saludos,
|