Una correcta manera de utilizar TFileStream capturando posibles excepciones variadas?

[mamcx]

Empezado por Delphius

Mi duda es ahora, si en el Create del TFileStream hay una excepción teóricamente con el uso del finally no hay forma de detectar que el archivo ha sido leído realmente.

Es más no tiene lugar siquiera el ReadMatrix que propones y no se realiza nada.

No entiendo cual es el bloqueo mental .

Si no se puede acceder al archivo, en que universo tiene sentido que lea la matriz?

Y que tiene que ver con que una excepcion surga del constructor? De que sirve que te deje crear el objeto, luego tengas un metodo "Open" y este falle... y luego que? Igual no puedes hacer nada.

Me tomo un tiempo darme cuenta, pero un objeto hecho asi es idiota:

Código Delphi [-]

TManejaUnRecursoComoBDArchivoRedEtc = class
    public
      constructor Create;
      destructor Destroy; override;
      procedure Open();
      procedure Close();
      procedure Write();
      procedure Read();
  end;

La razon? Ningun otro metodo tiene sentido si Open falla! Toca estar chequeando "Hey, de verdad puedo seguir?" y repetir en N-lugares "No se puede, porque la conexion no esta abierta".

Mucho mejor Asi:

Código Delphi [-]

function openRecurso():TManejaUnRecursoComoBDArchivoRedEtc
begin
   //Aqui abrimos
  // Y retornamos la clase. Ya sabemos que esta abierta y simplificamos todo el codigo.
end;

TManejaUnRecursoComoBDArchivoRedEtc = class
    public
      constructor Create(abierto:TRecurso);
      procedure Close(); //Solo si en lenguajes con GC, porque Delphi se puede hacer close en el destroy
      
      //Ahora todo tiene sentido!
      procedure Write();
      procedure Read();
  end;

Este es un ejemplo donde el manejo del estado (manual) tiende a complicar las cosas.

---

Recuerda lo de la idea del "supervisor"? Bueno, Quien debe decidir que sucede si las cosas fallan es quien invoque a "LoadMatrix". La razon?

Porque asi como si no puesdes abrir el archivo, no tiene sentido invocar escrituras y lecturas - y el *porque no abrio el archivo* no IMPORTA en ese caso, porque IGUAL no puedes ni leerlo ni escribirlo!; de la misma manera, si *LoadMatrix* falla, el que lo invoco igual se frejo, que alla sido por la razon que sea? NO IMPORTA. Porque igual, no se cargo la matriz!

Ahora, lo que realmente sigue es pensar: Cual es la estrategia de supervision. Reintento? Aborto? Espero a que llamen al tecnico? Pongo eso en un log?

Nota como el manejo de la "ruta feliz" solo le importa que sucede cuando hay exito, y el supervisor solo le importa cuando hay fracaso. Pero conceptualmente, es bueno tenerlos separados.

Nota: "conceptualmente". No hay ningun lio en poner eso dentro de un try/finally. Lo unico importante, es pensar: Esto es si todo ok, esto es si no. Y no mezclar ambos, en la medida de lo posible (asi como el acto de poder abrir un recurso es una cosa, y poder operar sobre el recurso, otra).