Una correcta manera de utilizar TFileStream capturando posibles excepciones variadas?

[Casimiro Noteví]

Pues yo no sabría responder con seguridad tu duda, así que mejor no contesto porque no quiero liarte más, a ver si alguien experto en el tema es capaz de iluminarnos.

Lo que sí quiero es saludarte, que hacía tiempo que no te veía, espero que todo te vaya bien

[[Delphius]]

Empezado por Casimiro Notevi

Pues yo no sabría responder con seguridad tu duda, así que mejor no contesto porque no quiero no liarte más, a ver si alguien experto en el tema es capaz de iluminarnos.

Lo que sí quiero es saludarte, que hacía tiempo que no te veía, espero que todo te vaya bien

Casimiro, me extraña de vos. Se que eres un maestro y sabes un montón. Asi que no me vengas con lo de hacerse de menos.
Cualquier aporte ayudará a este pobre loco.

Gracias por el saludo. Se agradece muchísimo. Lamentablemente debo informar que mi situación personal no es del todo buena. Estoy con un pié en la calle; prácticamente sin plata en mis bolsillos, y las oportunidades comerciales y profesionales no son muy alentadoras.
Tengo que confesarte que desde que empecé mis estudios universitarios quien debían en teoría debe dar apoyo lo único que ha hecho fue acortarme las posibilidades de desarrollarme profesionalmente y constantemente ha estado cerrando las puertas que yo por mis medios estuve tratando de abrilas. Las situación ya era tan insorportable que para evitar un mal mayor, tuve que abandonar mi lugar de residencia y buscar hospedaje en otros lugares. Ya debo volver en unos días y estoy seriamente convencido de iniciar acciones legales contra esta persona de no lograr que desaparezca y me deje tranquilo y al resto. Demasiado daño ha causado al círculo familiar. En realidad son 16 años de tortura, pero desde que cumplí los 18 se ha vuelto peor y no dejan de llegarme comentarios de los desmadres que ocasiona a terceros. Basta con decir que algunos de mis amigos de Facultad no han querido pisar más mi casa para no tener problemas con él; e incluso una psicóloga conocida me ha sugerido que lo deberíamos de internar bajo tratamiento psiquiátrico. Intenté que las cosas mejoraran por las buenas, y mucho me aguanté y tragué pero veo que tendrán que ser por las malas.
Actualmente estoy tratando de terminar unos proyectos, y quisiera ver si de una vez logro concretar que se cierre algunas ideas comerciales que vengo pensando y me han sugerido mis amigos que me quedan en contacto y tengo más a mano. Lamentablemente por el tipo de formación que he recibido y los gustos y aficciones a ciertos temas que por acá pocos manejan no hay mucho mercado. No queda otra que jugar a la Oferta para generar Demanda.

Bueno, mejor volvamos el hilo a su cauce normal.

Saludos,

[mamcx]

He estado aprendiendo mucho últimamente sobre programación funcional, en especial con F#.

Este articulo lo recomiendo muchísimo:

http://fsharpforfunandprofit.com/fppatterns/

Pongo esto porque conceptualmente aclara muchas cosas, lo que es mas "difícil" es aplicarlo a un lenguaje OO. Afortunadamente, Delphi es lo suficiente flexible y resulta mas simple que con Java!

Ahora voy a varios puntos:
---

he notado que todos los códigos de ejemplo no protegen la creación de

Lo cual es correcto, tanto conceptual como técnicamente. En vez de irme por las ramas, un concepto muy practico que viene del lenguaje funcional Erlang es:

"Fallar de inmediato"
https://www.sics.se/~joe/thesis/arms...hesis_2003.pdf

(Secciones 4.3 / 4.4).

En resumen? La forma correcta de hacer programas robustos es no hacer programación "primariamente" defensiva, sino permitir fallar rápido, y tener un "supervisor" que se encargue de aplicar una política de recuperación.

Error handling in Erlang is radically diferent to error handing in most
other programming languages. The Erlang philosophy for handling errors
can be expressed in a number of slogans:

• Let some other process do the error recovery.
• If you can’t do what you want to do, die.
• Let it crash.
• Do not program defensively.

Que es casi exactamente lo que sucede aquí. Si la creación del stream fracasa, NO TIENE SENTIDO SEGUIR ADELANTE. Es responsabilidad de su "supervisor" (ie: Quien llamo al método donde se intento crear el stream) determinar que hacer (reintentar? Abortar todo el sistema? Notificar y esperar un tiempo? etc).

Esto significa que solo te debes preocupar por resolver el problema a mano, no todos los posibles. Intentar aplicar una programación excesivamente defensiva es un anti-patron, que lleva a tonterías como:

Código Delphi [-]
try
//Alguna cosa
except:
  //No hacer nada o suponer que el error fue de permisos insuficientes!
end;

Es curioso, porque el uso de excepciones es una forma simplista de aplicar lo que dicen en Erlang, el problema es que la gente no le pone cuidado a lo que lees. Como es? "EXCEPCIONES", solo, "EXCEPCIONAL!". Una vez manejado (si acaso) lo excepcional, debe andar en la "ruta feliz" donde se asume que todo ira bien.

Te preguntaras porque arranco por aquí. Es simplemente porque quiero que solo te preocupes por "resolver el problema que tienes a mano", lo cual, lleva a hacer funciones/métodos cortos y faciles de testear.

Esa es la tesis del creado de Erlang. Y Erlang es famoso por ser el lenguaje/runtime mas robusto de todos, asi que tienen de donde saber porque es mejor asi

--

La segunda tesis importante que se aprende con programación funcional, es que el "manejo de estado" es una de las principales razones de la complejidad no esencial en el desarrollo de software. Eso se nota en tu código con el asunto de la variable ConvE.

La pregunta es: Como hago el código, que siga el modelo de la computacion I/O: Entrada -> Proceso -> Salida, con el minimo de dependencias y estado no esencial?

---

Ahora como lo aplicaria yo (no testee el codigo, solo lo reformatee), sin desviarme mucho del estilo que tienes:

Código Delphi [-]

function LoadFile(FileName: string):TFileStream;
begin
    Result := FFile.Create(FileName, fmOpenRead or fmShareDenyWrite);
    //FInUse := true; Redundante: El OS ya hace esto
    //Hasta
    FFile.ReadBuffer(Fmt.IDEnd, SizeOf(Fmt.IDEnd)); // ID.End
end;

procedure ReadMatrix(AMatrix: TAMatrix; FFile: TFileStream; RM, CM:Int);
begin
    // Mover los problemas mas cerca de donde se detectan!
    if not(ISValidFormat(Fmt, Header)) then 
    begin
        raise EFileOperation.Create('Invalid matrix file format');
    end;

    if not((Header.Rows = RM) AND (Header.Cols = CM))then
    begin
        raise EInconsistentArray.Create('The dimensions of the matrix and file data do not match', itDimNotMatch);
    end;

    //Ahora vamos por el "Happy Path!"
    // Leemos data
    if Header.Orientation = aoCol
     then begin
            // ... por columnas
            for j := 0 to CM - 1 do
              for i := 0 to RM - 1 do
                FFile.ReadBuffer(AMatrix[i, j], SizeOf(TYPEDATA));
          end
     else begin
            // ... por filas
            for i := 0 to RM - 1 do
              for j := 0 to CM - 1 do
                FFile.ReadBuffer(AMatrix[i, j], SizeOf(TYPEDATA));
          end;
    end    
end;

procedure TArrayConverter.LoadMatrix(AMatrix: TAMatrix; FileName: string);
var Header: TMatrixHeader;
    Fmt: TFileFormat;
    i, j, RM, CM, Err, ConvE: integer;
    Can: boolean;
begin
    Can := CheckMatrix(AMatrix, RM, CM, Err);
    if not(Can AND (Err = OPERATION_DONE)) then 
    begin
        EInconsistentArray.Create('Check of matrix failed', itCheck)
    end;

    FFile = LoadFile(FileName);
    try
        ReadMatrix(AMatrix, FFile, RM, CM);
    finally
       FFile.Free;
    end;
end;

Podras notar varias cosas:

1- Eliminar el nesting hacer mucho mas legible el código, mas de 3 niveles de identacion suele ser una mala señal

2- Poner cerca la detección de los problemas, hace mas claro el codigo (y concuerda con "fallar rápido" ie: poner primero fallar, luego el "happy path")

3- Es mejor programar con el "happy path" o la ruta feliz: Una vez que estoy en la ruta feliz, se asume que todo debe funcionar ok, a menos que algo realmente inesperado suceda (como quedarse sin memoria) donde la única opción sana, es matar el programa.

4- El uso de "FInUse" no le veo sentido: Si lo que quieres es decir que el archivo esta en uso, no es tu codigo, sino el OS, quien realmente sabe si es verdad y quien es el responsable.

Si lo que quieres es evitar que se carguen 2 veces el archivo, esa no es la manera robusta.

5- Separar en funciones es algo que me gusta porque simplifica la lectura, pero en este caso con la reduccion de la identacion y mover la deteccion quedaria igual de chulo.


Aun mas que se puede hacer, pero no quise hacer un cambio muy radical, y como hace un rato que estoy oxidado con Delphi y estoy muy metido con otros lenguajes no quise hacer algo muy alienigena

[[Delphius]]

Gracias Mamx por colaborar.

Estuve pensando en un método tipo PrepareStream() que bien o regrese un valor boolean o una excepción para determinar si algo ha fallado pero no he probado esta opción.

Tengo que pensar un poco tu propuesta. Se ve interesante el enfoque.

Te comento el porqué de la propiedad InUse. La clase está pensada a modo singleton (aunque no hay un control estricto en ello, y nada que impida crear varias instancias) debido a que es posible invocarla desde más de 2 módulos/clases independientes. De este modo, desde cualquier parte interesada en invocarla sepa si está disponible. No vi estrictamente necesario hacerlo por la vía Observer ya que no espero demasiada cosa.

Saludos,

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

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