Verificar si una imagen existe

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

[Casimiro Noteví]

No había entrado en este hilo hasta ahora y he descubierto que está interesante.

Bueno, voy a dar mi opinión, que es un poco radical, y así se monta polémica

Soy partidario de dar al usuario la información mínima, clara y sencilla sobre lo que está haciendo, sobre su trabajo. Sin embargo, sobre asuntos técnicos, problemas, errores y todo eso... prefiero ocultárselo por completo.

Lo que hago es dirigir todos los mensajes de errores, excepciones, etc. a un fichero de texto (.log). En este fichero sí que guardo detallado el error producido, en qué módulo, qué se hacía en ese momento, valores de las variables implicadas, la fecha y hora, el error devuelto por el sistema, etc...

Si el usuario detecta algún problema o comportamiento anómalo, éste no verá ningún mensaje de error que le asuste ni ninguna excepción que le cierre el programa, pero sí que puede ver que ha ocurrido algo extraño, por ejemplo (por decir algo): el total de una factura no es igual a la suma de las líneas de ventas que la compone.

Lo que hago es mirar el fichero .log e intentar descubrir el problema según la información almacenada en el mismo.

Y es que no me gusta sacar información técnica al usuario porque no la entiende ni le sirve de nada. He visto casos de personas que me han llamado llorando (no exagero) ante una pantalla con un mensaje de error y pidiendo ayuda para que su jefe no le despida.

[dec]

Hola,

Empezado por Casimiro

Soy partidario de dar al usuario la información mínima, clara y sencilla sobre lo que está haciendo, sobre su trabajo. Sin embargo, sobre asuntos técnicos, problemas, errores y todo eso... prefiero ocultárselo por completo.

Vamos a ver, vamos a ver... ¿qué información técnica te parece un mensaje de error del tipo: "No se pudo abrir el archivo indicado. Por favor, asegúrese de que el mismo existe e inténtelo de nuevo. Contacte con el Servicio de Soporte si necesita ayuda. Disculpe las molestias".

¿Dónde está lo técnico ahí? Y nada te impide guardar (por otro lado) la información técnica que quieras para después poder consultarla si fuera menester. Como dices ahora:

Empezado por Casimiro

Lo que hago es dirigir todos los mensajes de errores, excepciones, etc. a un fichero de texto (.log). En este fichero sí que guardo detallado el error producido, en qué módulo, qué se hacía en ese momento, valores de las variables implicadas, la fecha y hora, el error devuelto por el sistema, etc...

Empezado por Casimiro

Si el usuario detecta algún problema o comportamiento anómalo, éste no verá ningún mensaje de error que le asuste ni ninguna excepción que le cierre el programa, pero sí que puede ver que ha ocurrido algo extraño, por ejemplo (por decir algo): el total de una factura no es igual a la suma de las líneas de ventas que la compone.

Alto. Aquí no puedo estar más en desacuerdo (creando polémica)

Dices que no mostrarías al usuario mensaje de error alguno... ni ninguna excepción... que le cierre el programa... pero, un momento, ¿las excepciones no existen, entre otras cosas, para evitar el bloqueo del programa y su cierre obligatorio?

Eso tengo entendido: el programa entra en estado de excepción, estas pueden controlarse y el programa puede continuar adelante (siempre que sea posible, claro está).

Pero, lo que me parece curioso es que no informes al usuario del error y pretendas que él se dé cuenta de que hubo algún problema porque el total de una factura no cuadra con las cuentas que estaba haciendo el usuario...

Eso me parece muy peligroso, en el sentido de que el usuario puede pulsar ENTER para cerrar la ventana que le muestra la factura y ni fijarse siquiera en el total... porque se fía del programa, que, en caso de observar algún problema le avisaría como está mandado.

El caso es que si no revisara "manualmente" el resultado (¿Pero no están para eso los programas?) y cerrara la supuesta ventana y el programa no le dijera nada... pudiera estarse guardando en la base de datos (o ni guardarse siquiera) datos erróneos... ¡y el usuario aún creerá que no pasa nada, que todo va bien!

Tú luego irías con tu "log" y le dirías, mira, aquí esta factura puede que no cuadre, porque resulta que un error que... "¿Qué error?", te respondería el usuario, "No, tú es que no lo viste, pero, efectivamente...", "¿Cómo que no lo ví? ¿Y qué dices? ¿Que esta factura no está bien? ¡Pero si está cursada (o como se diga) junto con las del mes pasado? ¿cómo no se me informó del problema?... ¡Llámenme al responsable de este desaguisado!" Y se oiría por ahí... ¡Casimiro, ha sido el puñetero de Casimiro!

Total, pabernosmatao.

[[Lepe]]

Al salir una excepción programada por mi, he visto como el usuario, como acto reflejo, pulsaba el botón de aceptar; me quedé alucinado, la ventana no se había terminado de dibujar y ya había pulsado Aceptar.

Su respuesta fue que "esa ventanita no era nada", estupendo... me harto de estudiar el flujo del programa ante excepciones y solo consigo mejorar los reflejos de los usuarios....

Si un coche se para, lo llevas al taller, si un programa da un fallo, "no es nada" y si se queda colgado se apaga y se enciende de nuevo.... problema resuelto .

Saludos

[dec]

Hola,

Según la leyenda (algo que leí hace tiempo no recuerdo en qué lugar) en el primer manual de los IBM PC (que ahora cumplen 25 años, parece ser) podía leerse lo siguiente:

Los usuarios de ordenadores se dividen en dos grupos:

1º Los que han perdido alguna vez sus datos.
2º Los que están a punto de perder sus datos.

Esto se decía, parece ser, para tratar de concienciar de la importancia de hacer copias de seguridad. Ahora bien, sabiendo como se sabe que hay usuarios que pasan, literalmente, de las copias de seguridad (están a punto de perder sus datos), estas, las copias de seguridad, por supuesto, deben realizarse obligadamente, cosa que saben bien los usuarios del encajados en el primer grupo.

¿Que se cierran las ventanas con mensajes de error informativos muchas veces sin siquiera mirarlas? Es una realidad, yo mismo reconozco que lo he hecho y que lo haré en ciertas ocasiones, y, sin embargo, no creo que eso dé pie a eliminar los mensajes de error informativos,... ¿cuántas veces no te queda más remedio que pararte un momento y leer lo que esas ventanas dicen, porque intuyes la importancia del mensaje?

Otra leyenda dice que hay que tratar a los usuarios de programas de ordenador como tontos (dicho mal y pronto), porque no son informáticos, ni saben de informática (ni tienen por qué, digo yo), ni conocen los intríngulis de los programas, etc., etc., etc. Yo no estoy de acuerdo con esa opinión, como ya he dicho: prefiero tomar a los usuarios como inteligentes, lo suficiente para pensar que leerán los mensajes de error informativos y los prestarán atención. ¿A mí qué se me dá que haya usuarios tontos (todos, alguna vez, actuamos así)? Prefiero estar con los otros, con quienes sí se preocupan de esas cosas.

Además, como he dicho, tal vez pases alguna vez de esas ventanas de error, pero, amigo, entonces uno pasa a ser un poco responsable del problema existente con el programa, porque el programa está diciendo, "Hey, me ocurre esto, ¿sabes? No puedo continuar, presta atención, pide ayuda, haz lo que sea, pero, que sepas que no estoy haciendo bien mi trabajo". Si no se le advierte al usuario de los mensajes de error informativos estás condenando a todos los usuarios, a todos ellos, a no poder hacer nada... me parece que es lo de siempre: pagan justos por pecadores, por decirlo así.

Porque los mensajes de error informativos no están ahí por estar, ni se ponen para hacer bulto, ni nadie quisiera que aparecieran, pero, puesto que los programas no son perfectos (y los usuarios tal vez menos aún, yo me incluyo) es necesario informar de los problemas que topan, reaccionar ante estos, intentar "tratarlos" (¿mediante excepciones?), aprender de ellos, en fin, como dije por ahí arriba, pienso que esto puede ayudar al usuario del programa y a sus desarrolladores, proporcionándoles información muy útil. ¿Que alguien pasa de esa información? En parte entonces es su problema, ya aprenderá de la necesidad de hacer copias de seguridad... tal vez cuando se tarde, cuando pierda sus datos al menos una vez...

Empezado por Casimiro

A donde quería llegar es que no sirve de nada sacarles mensajes con códigos, números ni nada que se salga del trabajo del usuario porque, simplemente, lo ignoran, como acaba de escribir Lepe, "Sí, sale un mensaje, pero lo quito y sigue funcionando".

Yo no he sido. O esa, yo nunca he dicho que al usuario hubiera de mostrársele mensajes del tipo "Excepción en el módulo X98237373, la memoria no se puede leer"... todo lo contrario. Al usuario hay que hablarle en su idioma... lo mismo que los menús de los programas no se llaman "Flujos de datos -> Leer un flujo de datos", sino "Archivo -> Abrir un archivo". Pero, cuando digo que al usuario hay que hablarle me refiero exactamente a eso: a tratar de mantener con él un diálogo comprensible acerca de qué está ocurriendo, acerca de los errores que se pueden producir y se producen. La idea es: hay gente que pasa de esos mensajes de error.

Pues muy bien, pero si el programa advierte, informa, especifica, quiere entablar un diálogo y un usuario pasa de él... luego se le podrá preguntar al usuario, ¿hiciste caso de lo que el programa te decía? "Ah, bueno, es que yo paso de los mensajes de error"... ¡que diga eso delante del jefe de turno en cualquier empresa que sepa del valor de su información digitalizada! En ese punto uno hasta podría decir, "pues son 10.000", porque de ese problema estábamos avisando, pero, si no se quiere hacer caso, como se reconoce, ¿qué quieren ustedes que hagamos?"...

No sé. Yo creo que mientras jugamos casi todo vale. Pero, cuando las cosas se ponen serias... decir "yo paso de los mensajes de error"... puede resultar causa de despido por incompetencia.

[[egostar]]

Hombre, para que tanto alboroto por los mensajes de error, si Microsoft nos da la mejor respuesta, aqui uno que tengo en mi visor de eventos.

Aplicación con errores: iexplore.exe, versión: 7.0.5450.4, módulo con error: unknown, versión 0.0.0.0, dirección de error 0x05b79984.

Para obtener más información, vea el Centro de ayuda y soporte técnico en http://go.microsoft.com/fwlink/events.asp.

Los usuarios de windows estamos tan acostumbrados a estos mensajes, de que hay un error hay un error.

Asi que ya saben pongan su direccion para que les llamen o acudan a ustedes cuando tengan errores en sus aplicaciones.

Saludos.

[Casimiro Noteví]

Empezado por dec

Hola,
Vamos a ver, vamos a ver... ¿qué información técnica te parece un mensaje de error del tipo: "No se pudo abrir el archivo indicado. Por favor, asegúrese de que el mismo existe e inténtelo de nuevo. Contacte con el Servicio de Soporte si necesita ayuda. Disculpe las molestias".

¿Dónde está lo técnico ahí? Y nada te impide guardar (por otro lado) la información técnica que quieras para después poder consultarla si fuera menester. Como dices ahora:

Alto. Aquí no puedo estar más en desacuerdo (creando polémica)

Dices que no mostrarías al usuario mensaje de error alguno... ni ninguna excepción... que le cierre el programa... pero, un momento, ¿las excepciones no existen, entre otras cosas, para evitar el bloqueo del programa y su cierre obligatorio?

Eso tengo entendido: el programa entra en estado de excepción, estas pueden controlarse y el programa puede continuar adelante (siempre que sea posible, claro está).

Pero, lo que me parece curioso es que no informes al usuario del error y pretendas que él se dé cuenta de que hubo algún problema porque el total de una factura no cuadra con las cuentas que estaba haciendo el usuario...

Eso me parece muy peligroso, en el sentido de que el usuario puede pulsar ENTER para cerrar la ventana que le muestra la factura y ni fijarse siquiera en el total... porque se fía del programa, que, en caso de observar algún problema le avisaría como está mandado.

El caso es que si no revisara "manualmente" el resultado (¿Pero no están para eso los programas?) y cerrara la supuesta ventana y el programa no le dijera nada... pudiera estarse guardando en la base de datos (o ni guardarse siquiera) datos erróneos... ¡y el usuario aún creerá que no pasa nada, que todo va bien!

Tú luego irías con tu "log" y le dirías, mira, aquí esta factura puede que no cuadre, porque resulta que un error que... "¿Qué error?", te respondería el usuario, "No, tú es que no lo viste, pero, efectivamente...", "¿Cómo que no lo ví? ¿Y qué dices? ¿Que esta factura no está bien? ¡Pero si está cursada (o como se diga) junto con las del mes pasado? ¿cómo no se me informó del problema?... ¡Llámenme al responsable de este desaguisado!" Y se oiría por ahí... ¡Casimiro, ha sido el puñetero de Casimiro!

Total, pabernosmatao.

Evidentemente, mensajes "amigables" sí que se los muestro, el ejemplo de la factura no ha sido muy afortunado.
A donde quería llegar es que no sirve de nada sacarles mensajes con códigos, números ni nada que se salga del trabajo del usuario porque, simplemente, lo ignoran, como acaba de escribir Lepe, "Sí, sale un mensaje, pero lo quito y sigue funcionando".