Una correcta manera de utilizar TFileStream capturando posibles excepciones variadas?

[Casimiro Noteví]

Creo recordar que en "La cara oculta de Delphi 4" había un capítulo sobre el tema.

Vaya situación personal la tuya, a ver si se arregla pronto, ánimos

[[Delphius]]

Empezado por Casimiro Notevi

Creo recordar que en "La cara oculta de Delphi 4" había un capítulo sobre el tema.

Vaya situación personal la tuya, a ver si se arregla pronto, ánimos

Es cierto, hay un capítulo que trata la teoría de las excepciones, y habla de las reglas de oro de cómo y cuando usarlas. Pero el mismo al final aclara que incluso esas reglas están hechas para romperlas. Tengo que admitir que tengo oxidada esa parte. Y es justamente entre esas cosas, lo que extraño tratar de hacer memoria a como iba y por ello es que acudo a los foros, a ver quien me hecha luz.

El tiempo que estuve fuera de la programación si que ha oxidado mi cabeza

Lo de arreglar mis problemas, no creo que desaparezcan prontamente. Va a ser una batalla dura seguramente. Ni te imaginas cuanto deseo desapegarme de eso, pero lamentablemente tuve que estar bastante embarrado para evitar que otros, más indefensos que yo, salieran más lástimado y controlar a que la bestia le salte más de lo normal los tapones contra otros. Lo que esperaba de mi ausencia es poner en evidencia de que si no saltan más fuerte los tapones es porque justamente yo era quien venía frenando a esa bestia (algún "provecho" tenía que haberle sacado a lo poco que aprendí de arte marciales). Van a tener que aprender a defenderse solas, no es posible que deba dejar mi vida para evitar que las golpeen y tener que tener un ojo siempre despierto vigilando a ver que trama el loco. Bastante he salido a defendarlas cada vez que piden auxilio. Lamentablemente tengo que sacar mi yo egoista.

Saludos,

[[Delphius]]

Mamx estuve examinando tu propuesta. Le faltaría pulir algunos detalles menores, pero puede que vaya bien encaminada.
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. Tal excepción pasa desapercibida, puesto que es una acción automática que realiza el compilador. Cuand hay una excepción en un constructor se suspende tal reserva de memoria y tiene lugar una liberación de los recursos que si hayan tenido lugar. El método LoadMatrix que propones no dejará a la matrix cargada con los datos del archivo, obviamente, pero no hay tal aviso.

Ese es el punto central. TFileStream es un caso particular en donde las reglas de juego no son tan genéricas. Normalmente no es de esperar un error en un constructor, pero el TFileStream explícitamente fue diseñado para arrojarlas si no ha sido posible crear o cargar el archivo y como tal hay que dar aviso de ello.

Mira esto:

Código Delphi [-]
constructor TFileStream.Create(const AFileName: string; Mode: Word);

begin
  Create(AFileName,Mode,438);
end;


constructor TFileStream.Create(const AFileName: string; Mode: Word; Rights: Cardinal);

begin
  FFileName:=AFileName;
  If (Mode and fmCreate) > 0 then
    FHandle:=FileCreate(AFileName,Mode,Rights)
  else
    FHAndle:=FileOpen(AFileName,Mode);

  If (THandle(FHandle)=feInvalidHandle) then
    If Mode=fmcreate then
      raise EFCreateError.createfmt(SFCreateError,[AFileName])
    else
      raise EFOpenError.Createfmt(SFOpenError,[AFilename]);
end;

Y no sólo así son las cosas, que hasta los ReadBuffer y el WriteBuffer den excepción:

Código Delphi [-]
  procedure TStream.ReadBuffer(var Buffer; Count: Longint);

  Var
    r,t : longint;

  begin
    t:=0;
    repeat
      r:=Read(PByte(@Buffer)[t],Count);
      inc(t,r);
    until (t=Count) or (r=0);
    if (tthen
      Raise EReadError.Create(SReadError);
  end;

  procedure TStream.WriteBuffer(const Buffer; Count: Longint);

  var
    r,t : Longint;

    begin
      T:=0;
      Repeat
         r:=Write(PByte(@Buffer)[t],Count);
         inc(t,r);
      Until (t=count) or (r=0);
      if (tthen
         Raise EWriteError.Create(SWriteError);
    end;

Se que tu propuesta es mucho más limpia, y va muy bien encaminada. Nomás me pregunto sobre la posibilidades de como debiera de tratarse esta clase tan particular.

Saludos,

[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).

[[Delphius]]

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,

[Casimiro Noteví]

Como indica mamcx, creo que estás cayendo en algo que todos hemos caído muchas veces (debe ser algo implícito en personas como nosotros) y es que siempre estamos buscando la perfección. Hace tiempo que me di cuenta que no es necesario ser perfecto, basta con controlar lo "imprescindible" y si falla algo, ahora sí, emitir un mensaje o guardar un log, para saber dónde ha fallado y solucionarlo.
Pero intentar ser perfecto hasta el infinito y más allá no vale la pena

[[Delphius]]

Empezado por Casimiro Notevi

Como indica mamcx, creo que estás cayendo en algo que todos hemos caído muchas veces (debe ser algo implícito en personas como nosotros) y es que siempre estamos buscando la perfección. Hace tiempo que me di cuenta que no es necesario ser perfecto, basta con controlar lo "imprescindible" y si falla algo, ahora sí, emitir un mensaje o guardar un log, para saber dónde ha fallado y solucionarlo.
Pero intentar ser perfecto hasta el infinito y más allá no vale la pena

No es que busque hacerlo perfecto, sólo espero controlar la separación cohesiva.
Para mi diseño es muy necesario poder controlar esta parte puesto que responde a una necesidad importante. No es un detalle menor el guardar y leer de archivos y que si algo falla vaya y pase. Me son vitales para que justamente en caso de problemas, y por sobre todo para poder continuar con el trabajo en otra oportunidad, tener un medio en donde almacenar los datos.
Justamente la clases clientes esperan delegar el trabajo de poder leer y guardar en archivos en esta clase TArrayConverter para mantenerse lo más cohesivos posibles. En vista a que en varios puntos del programa me es necesario estar guardando y leyendo de archivos la clase TArrayConverter es más que justificada.
No vale la pena el uso de bases de datos, de hecho inicialmente lo estuve considerando pero tener una representación matricial en una DB es algo más trabajoso.

Saludos,

[mamcx]

Empezado por Delphius

Lo de arreglar mis problemas, no creo que desaparezcan prontamente. Va a ser una batalla dura seguramente.

Lo que dices tiene mala pinta, e internet es un pésimo lugar pa tratar temas tan serios. Solo dire que puede ser buena idea considerar pedir ayuda profesional, hacer denuncias a la justicia si es del caso, y buscar consejo de personas capacitadas en manejar esos asuntos.

[[Delphius]]

Empezado por mamcx

Lo que dices tiene mala pinta, e internet es un pésimo lugar pa tratar temas tan serios. Solo dire que puede ser buena idea considerar pedir ayuda profesional, hacer denuncias a la justicia si es del caso, y buscar consejo de personas capacitadas en manejar esos asuntos.

Lo se mamx. Sólo me permito un poco de catársis, que ya llevo bastante tiempo guardando si no exploto. Seguro que voy a recurrir a la justicia, aunque ya lo he intentado otras 3 veces. Obvio que es cosa seria, bastante. Pero si me permito la licencia de decirlo por acá es porque tengo la confianza suficiente y porque estoy decidido a acabar con esto de manera personal ni bien retorne.

Saludos, y gracias por tus consejos.