Verificar si una imagen existe

[roman]

Empezado por dec

¿Habrá más aún?

Esto es trampa En este caso específico, por las razones que menciona seoane, estoy de acuerdo. Pero en general no me gusta usar excepciones a diestra y siniestra cuando hay formas de preveer el posible error. Ya anteriormente hemos discutido esto y me quedo con lo que indica la misma ayuda de Delphi.

// Saludos

[[Lepe]]

Supongo que "preveer hasta cierto punto", porque si tenemos que comprobar que el fichero:
- existe
- es un jpg
- no está corrupto

Hecho mediante try.. except, try finallys y demás... me parece demaisado.

En este caso, teniendo una ventana de Inventario por detrás y muy posiblemente una base de datos, yo simplemente haría un Try ... except, y dentro del except pondría en un estado estable las variables que puedan dar efectos colaterales, despues, lanzaría mi propia excepción.

Con código:

Código Delphi [-]
procedure TformInventarios.proCargarImagenes(Im: TImage; ruta: String; imagen: String);
var
ImgExt: String;
begin
  Im.Stretch:= True;
  try
    Im.Picture.LoadFromFile(ruta + imagen + '.JPG');    
  except
     if im <> nil then // chequeamos no nos salte otra excepcion aqui  
       im.picture.Clear;
      ruta := EmptyStr;
      imagen := EmptyStr;
      raise Exception.CreateFmt(' la imagen %s%s no se ha podido cargar',[imagen, ruta]);
  end;
end;

Saludos

[courtois]

y que mas?, no se cargó la imagen? por que? o que? asi nadamas sin explicación? si digo que no esta el jpg no le ayudo en algo a mi usuario?
y si digo que si está pero está corrupto no le ayudo tampoco?

[dec]

Hola,

Bueno. Supongo que dentro del bloque "try...except" puedes "mirar" por distintos tipos de excepciones (que creo que por ahí van los tiros, que vamos al todo o nada, cuando existen distintos tipos de excepciones, e incluso los que nosotros podemos crear por nuestra cuenta). De ese modo podrías indicar al usuario más o menos por dónde van los tiros, qué puede estar fallando. ¿No?

[[seoane]]

Empezado por courtois

y que mas?, no se cargó la imagen? por que? o que? asi nadamas sin explicación? si digo que no esta el jpg no le ayudo en algo a mi usuario?
y si digo que si está pero está corrupto no le ayudo tampoco?

Si lo que necesitas es información que te parece esto:

Código Delphi [-]
procedure CargarImagen(Imagen: TImage; Filename: String);
begin
  try
    Imagen.Picture.LoadFromFile(Filename);
  except
    on EInvalidGraphic do
    begin
      ShowMessage('No reconozco este tipo de grafico');
    end;
    on EFOpenError do
    begin
      ShowMessage('No puedo abrir archivo: ' + SysErrorMessage(GetLastError));
    end;
    on EOutOfResources do
    begin
      ShowMessage('No hay mas recursos disponibles: ' + SysErrorMessage(GetLastError));
    end;
    on E: EOSError do
    begin
      ShowMessage('Error del sistema: ' + SysErrorMessage(E.ErrorCode));
    end;
    on EReadError do
    begin
      ShowMessage('Error de lectura, puede que el archivo este corrupto');
    end;
  else
    begin
      ShowMessage('Error desconocido');
    end;
  end;
end;

Los mensajes podrían ser mas explícitos pero el SysErrorMessage nos dará mas información sobre lo que paso (si el archivo no existe, si no tenemos permiso para leerlo, etc)

[[Lepe]]

ok, pero eso es para cargar una imagen... si despues necesitamos cargar un fichero de texto, hay que hacer algo parecido (las excepciones cambian), si vamos a crear en memoria una lista de objetos... pongamos 10, pues tambien hay que crear una rutina .... ¿ves por donde voy?

Cada operación a realizar puede involucrar fallos, intentar evitarlos todos te llevaría 4 veces más, en tiempo y presupuesto, ¿tu cliente estará de acuerdo?, en cuanto al dinero seguro que no. No queda más remedio que controlar "superficialmente" ese tipo de fallos.

El usuario coge un archivo jpg, le cambia la extension a bmp (porque nuestro programa solo damos soporte a bmp) y .... ¿para eso le das un mensaje específico de ese fallo?... por dios, ese tipo sabe lo que hace; si no lo sabe y le da el error, pues le decimos que tiene que usar el paint [...] pero de ahí a controlar todos los errores que pueden dar... parece demasiado.

El cliente te contrata para hacer un programa que "haga lo que él quiere" pero no pide un control exhasutivo de errores, es más.. decirle que se ha producido un error de "entrada / salida" le va a ayudar muy poco, creemé. Por otra parte los usuarios quieren programas sin tecnicismos, de lo contrario haces que parezcan ignorantes o tontos (aunque lo sean ).

A veces, viendo los conocimientos que tiene nuestro cliente de informática damos más o menos información... pero el que usa el programa puede cambiar (despido de empleado, nueva contratación), ¿y si ahora tiene menos conocimientos? ¿le quitas/modificas los mensajes de error porque no lo entiende?

y si digo que si está pero está corrupto no le ayudo tampoco?

Lo primero que responderá al ver ese mensaje es: "coño, ¿la corrupción en Marbella se ha propagado tambien a este programa?"

  else
    begin
      ShowMessage('Error desconocido');
    end;

En este caso... mejor no decirle nada al usuario, o los ignorantes seremos nosotros.... "mira que hacer un programa y no saber el fallo"

Saludos

[dec]

Hola,

Empezado por Lepe

(...) si despues necesitamos cargar un fichero de texto, hay que hacer algo parecido (las excepciones cambian) (...)

Pues de las que ha puesto Seoane más arriba creo que la única que "no valdría" sería la primera, pero, el resto me parecen a bote pronto perfectamente válidas para el caso de tener que cargar un archivo de texto.

Empezado por Lepe

Cada operación a realizar puede involucrar fallos, intentar evitarlos todos te llevaría 4 veces más, en tiempo y presupuesto, ¿tu cliente estará de acuerdo?, en cuanto al dinero seguro que no. No queda más remedio que controlar "superficialmente" ese tipo de fallos.

No puedo estar de acuerdo. ¿Eso no sería parecido a no hacer que una página Web mantenga un código XHTML válido tan sólo porque el cliente no va a notar la diferencia? Puede que no note la diferencia, pero, es que tener un código "válido" también sirve al desarrollador del mismo, te lo aseguro. Por otro lado, ¿es más caro escribir código XHTML válido que HTML de cualquier manera? Creo firmemente que no.

Empezado por Lepe

El usuario coge un archivo jpg, le cambia la extension a bmp (porque nuestro programa solo damos soporte a bmp) y .... ¿para eso le das un mensaje específico de ese fallo?... por dios, ese tipo sabe lo que hace; si no lo sabe y le da el error, pues le decimos que tiene que usar el paint [...] pero de ahí a controlar todos los errores que pueden dar... parece demasiado.

¿Y cómo se lo dices al usuario? ¿Con un mensaje, aunque no sea de error? Yo creo que el manejo de excepciones es una buena cosa, que habría que programar teniéndolo en cuenta y que esto puede ayudar no sólo al usuario, pero, como antes, también al desarrollador (y futuros desarrolladores) de un programa.

Ahora, es cuestión de "perder" la costumbre de hacerlo de otro modo: hay que recordar que las excepciones no están aquí desde siempre, que antes los errores se trataban de otro modo, pero, que, también, las excepciones han venido para quedarse... quiero pensar que por algo será... porque se las ve útiles: son una mejor forma de tratar los errores que como se hacía antes, a base de "prever" posibles problemas... esto suena muy complejo... ¡prever cualquier problema! Buf...

Empezado por Lepe

El cliente te contrata para hacer un programa que "haga lo que él quiere" pero no pide un control exhasutivo de errores, es más.. decirle que se ha producido un error de "entrada / salida" le va a ayudar muy poco, creemé. Por otra parte los usuarios quieren programas sin tecnicismos, de lo contrario haces que parezcan ignorantes o tontos (aunque lo sean ).

¿Porqué le vas a decir al cliente que existe un error de entrada/salida y nada más? Pero a ti puede venirte muy bien saber que existe un error de entrada/salida, por ejemplo, en un reporte de error que el propio programa podría encargarse de preparar e incluso enviar por correo, por ejemplo. Al cliente puede dársele esa información y alguna adicional, como, por ejemplo, "error de entrada/salida, probablemente el archivo que está tratando de abrir ya no existe en la ubicación especificada".

Empezado por Lepe

A veces, viendo los conocimientos que tiene nuestro cliente de informática damos más o menos información... pero el que usa el programa puede cambiar (despido de empleado, nueva contratación), ¿y si ahora tiene menos conocimientos? ¿le quitas/modificas los mensajes de error porque no lo entiende?

Aquí volveré a repetir que el tratamiento de las excepciones en un programa no sólamente puede venirle bien al usuario del mismo, pero, a los propios desarrolladores. Pueden proporcionar información muy útil, y, bueno, se supone que las excepciones "se tratan", impiden que un programa entre en estado "de error" y se mantenga en cierto estado de "excepción" que puede controlarse.

Empezado por Lepe

Lo primero que responderá al ver ese mensaje es: "coño, ¿la corrupción en Marbella se ha propagado tambien a este programa?"

Sí; puede que si a un usuario le dices de plano que un archivo está corrupto no entienda muy bien el mensaje, pero, vuelvo a lo de antes, siempre puede dársele la información "traducida" a un lenguaje, digamos, más comprensible... "El archivo que está intentando abrir parece corrupto. Esto generalmente significa que el contenido del archivo no puede ser leído correctamente. Disculpe las molestias, por favor, revise que el archivo seleccionado sea un archivo válido. Póngase en contacto con el soporte técnico si necesita ayuda." Puede parecer largo, si se quiere lo matizamos, pero, más o menos creo que se entiende la idea: trata al usuario como te gustaría que te trataran a ti.

Empezado por Lepe

En este caso... mejor no decirle nada al usuario, o los ignorantes seremos nosotros.... "mira que hacer un programa y no saber el fallo"

Te refieres a si no puede averiguarse cuál es el error, problema o excepción, mejor dicho, con la que hemos topado, pero,... ¿no decirle nada al usuario le ayuda en algo? Se supone que el programa no podrá hacer su trabajo,... ¿y le dejamos al usuario con un palmo de narices? Además, pienso que no decirle nada al usuario impide algo importante: lo que el usuario pueda decirnos a nosotros... así que, si se trata de un error desconocido, bueno será saberlo, para empezar a tratar de conocerlo mejor...

Disculpad el rollazo. Admito réplicas.

[[Lepe]]

No, no pienso contestarte a todo ni replicarte, se me haría muy largo .

Mi criterio: Al usuario, los mínimos detalles técnicos posibles, si acaso procede, un código de error, (el numerito), simple para mí y simple para el usuario.

Crear tantos tipos de excepciones como haga falta en el programa, despues se muestran las que parezcan oportunas y las demás no. cualquier excepción al tiempo de realizar la facturación no se puede pasar por alto, Un Image1.LoadFromFile que despues se guarda en la base de datos, puede tratarse como antes he mencionado, revisa el código, en el except lanzo otra excepción .

Todas las excepciones a un archivo .TXT (y esto es muy importante). Si hace falta, que él mismo me lo envíe por correo. Recuerdas debuguear en tiempo de ejecución... pues eso .

¿Cuantas veces envías a Microsoft los fallos de Windows? ¿y de otros programas? Yo no me fío si lo que veo en pantalla es lo que se envía realmente, por eso, tomo la misma filosofía en mis programas.

Yo solo expongo lo que a mi parecer es lo más adecuado, podreís estar de acuerdo o no .

Saludos

[[seoane]]

Estoy de acuerdo contigo Lepe, yo cuando tengo que cargar una imagen ante cualquier excepción muestro el mensaje "No puedo cargar la imagen", si el usuario sabe lo que hace ya se imaginara porque es el fallo y si no lo sabe poco le vamos a aclarar dándole detalles técnicos. De todas formas siempre habra algun fallo que no se tuvo en cuenta y saldra el mitico mensaje de error: "Error desconocido" que da la sensacion de que el programador no sabia lo que estaba haciendo

Pero si te fijas yo empecé mi respuesta diciendo:

Si lo que necesitas es información que te parece esto:

si no es imprescindible para que complicarle la vida al usuario con complejos mensajes de error.