![]() |
Verificar si una imagen existe
Hola Amigos del foro:
Tengo un problema, estoy cargando imágenes con TImage pero esto lo hago dinámicamente con una cadena de la base de datos lo que pasa es que no puedo controlar si una imagen existe, cuando el sistema no encuentra el archivo me manda una excepción como puedo controlar si el archivo existe o no este es el código que estoy utilizando
Espero puedan ayudarme, gracias. |
|
Saludos
También con la función FileExists
|
Agradecimiento
Gracias por responder me ayudaron a resolver el problema que tenia.
|
Hola,
Cita:
Cita:
¿Y qué pasa luego? ¿Os creéis que podéis iros de rositas luego de dejar ese código fuente ahí, como el que no quiere la cosa? ¿O qué? ¿Con cuál me quedo? ¿Hago uso de las excepciones? ¿Utilizo la función "FileExists"? ¿Hago lo que quiera? ¿Sería más "lógico" (respeto tengo a esta palabra) elegir el camino de la excepción? ¿Acaso no es la función "FileExits" una reliquia de la época aquélla en que no se conocían las excepciones? Si no es por discutir, y menos con la que está cayendo (en Oriente Medio y acaso en otros lugares),... si no es que quiera armar aquí un "flame" ni nada de eso... se trata simplemente de que opinéis, si queréis, claro. :eek: :eek: :D :D |
Si es cuestión de defender una opción, yo sigo optando por las excepciones. No porque no sea perfectamente valida FileExists, sino porque esta solo comprueba que el archivo existe pero no que sea una imagen valida. Si resulta que el archivo en cuestión no es una imagen o esta corrupto no enfrentaríamos a una excepción no controlada. Así que de usar FileExists también seria necesario usar try ... except y por eso de economizar código mejor usar excepciones directamente y nos ahorramos un paso.
¿que te parece ahora dec? :D |
Con esos argumentos, creo que me ganó:(
Saludos |
Hola,
Cita:
Cita:
|
Cita:
// Saludos |
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:
Saludos |
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? |
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? :) |
Cita:
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) |
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 :D). 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? Cita:
Código:
else Saludos |
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 :D
Pero si te fijas yo empecé mi respuesta diciendo: Cita:
|
Hola,
Cita:
Cita:
Cita:
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... Cita:
Cita:
Cita:
Cita:
Disculpad el rollazo. Admito réplicas. :D :D |
No, no pienso contestarte a todo ni replicarte, se me haría muy largo :D.
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 :p. 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 |
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 :D 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. |
Hola,
Cita:
¿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: Cita:
Cita:
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. :D :D :D 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! :D :D Total, pabernosmatao. ;) |
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 :eek:. Saludos |
Cita:
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". |
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: Cita:
¿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... Cita:
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. |
Cita:
Lo normal es que siempre digan: "el programa falla", aunque el responsable sea el propio usuario |
Cita:
|
Hola,
Cita:
Si tú haces tu trabajo informando al usuario de los problemas y éste pasa de ti y de la información que le proporcionas... allá él. Tú hiciste tu trabajo. Que cada palo aguante su vela. Cita:
Y estos problemas pueden venir de varias fuentes: hardware, software, humanos... pero todos son problemas y no vale de nada decir, ah, no es culpa mía, acusando a otros, sino que habrá que tratar de solucionarlos, vengan de donde vengan. |
Cita:
Y es que hay gente para todo, y cuando se trata de "salvar el culo" hacen o dicen cualquier cosa. Y con los años, a fuerza de golpes, he aprendido que tengo que mantener un registro de TODO lo que hagan los usuarios, aunque ellos no lo sepan, para en caso de necesidad, usarlo como "prueba del delito" y salvarme/nos (la empresa). Hay mucha gente con muy "mala sangre" por ahí... y aunque te lleves muy bien con ellos y sea tu mejor cliente... a la hora de los problemas siempre suena un "¡¡¡ sálvese quien pueda!!!. Y hay que estar preparado. P.D. Incluso envío el .log por FTP a un servidor de datos donde se van almacenando todos los .logs de los clientes. Esto sí lo saben, por supuesto, "es para solucionarles problemas en caso de necesidad". |
Cita:
Normalmente, delante de otra gente dirá "que pasa de los mensajes" delante de tí dirá que no se acuerda de lo que decía, o simplemente te dice que no lo entendió. Saludos |
Hola,
Cita:
|
Cita:
Le he dicho que no es culpa mía/nuestra, que habrá que actualizar el antivirus, eliminar los que tenga, y volver a instalar el programa, etc... y ha contestado que "acabo de devolver el último recibo que os tengo que pagar, y no pienso pagarlo hasta que me soluciones este fallo":confused::confused::confused: Y es que siempre es "fallo" del programa o de los programadores :D Le he pasado una nota al jefe para que lo llame y se aclaren entre ellos, ahí ya, con dinero de por medio, yo no me meto. |
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.:mad:
Cita:
Los usuarios de windows estamos tan acostumbrados a estos mensajes, de que hay un error hay un error.:D :D :D Asi que ya saben pongan su direccion para que les llamen o acudan a ustedes cuando tengan errores en sus aplicaciones.:D Saludos. |
Cita:
// Saludos |
El problema del manejo de errores es muy interesante. Me voy a referir a lo que me parece mejor:
1. Un programa es un conjunto de errores, que coincidencialmente, da resultados. Existen multiples capas de error entre la CPU y el usuario, y lo peor que puede pasar es un programa que no saque error. Es pesimo, porque todo programa OBLIGATORIAMENTE tiene un error. Y si no lo tuviera, OBLIGATORIAMENTE la capa anterior lo TIENE que tener, por ejemplo, si es un exe, la capa anterior es el shell, de alli al OS, sistema de archivos, memoria, CPU, etc... Si es una pagina Web, el error esta en la pagina. O en el navegador, o la comunicacion http o la de fondo tcp/ip o falla el DNS o lo tiene la version X del servidor Web, o en la seguridad o la Base de datos o el OS y de alli ya sabemos. Muchos puntos de falla, donde nunca estan cubiertas todas las rutas de ejecucion. Por lo tanto, una regla que he tenido es solo cubrir los casos esperados y dejar que el condenado programa falle en toda su gloria. Porque ya me ha tocado depurar software en donde arranco en un http GET, donde esta muy lento, luego descubro que el servidor DNS esta sobrecargado (pero el DNS se cachea, no? seria muy raro. Sin embarggo en este caso de este mes, la pagina era lenta el 25% del tiempo, 24*7), luego de pelear con los clientes y con una de las mejores firmas locales en manejo de redes donde cuestionaron el problema, nos vamos mozilla, corro por IE, volteo por el ISA server, las politicas de cacheo DNS de windows y en fin, fueron 8 puntos de falla en total que conspiraron todos juntos. Al final, si era el DNS + Firefox/IE + OS + Servidores intermedios de internet + ISA Server + Maquina con baja memoria + puros restart en el proceso de ASP.NET + poco espacio en disco de la BD. Y este fue facil. Ya intuia que era el DNS sobrecargado pero demostrar *porque* esa fue toda una mision de 12 horas de analisis. Por eso, se deberia apedrear a todo programador que haga esto:
El silencio es una politica para un ataque sorpresa militiar. Tambien causa sorpresa en los programas. 2. Una excepcion es una excepcion. No tiene mas significado. Si sabes que va a pasar, no es excepcional. Mientras un try...finally es util en una infinidad de casos, el try..except hay que reservarlo para cosas poco usuales, y solo para corregir una situacion. Si es un caso muy obvio que un archivo no exista, no es excepcional. Deberia haber un codigo EXPLICITO. Y ser explicito es mejor que ser implicito. Sobre todo, para nosotros los hombres que tenemos poquito de intuicion ;) Si pongo:
Estoy siendo explicito en mi criterio: El codigo es valido solo si el archivo existe y de alli lo proceso. Pero
Estoy diciendo, que cuando ocurra un error, hago algo. Eso es <> a decir: "Cuando el archivo exista, lo abro" <> "Abro el archivo. En cualquier punto de falla, hago esto" Un uso excepcional es por ejemplo que este cargando el archivo INI de configuracion de la aplicacion, que se supone siempre esta ahi, pero en caso que no, que es algo poco probable, hago esto otro. Y sin embargo, ya que lo resolvi, dejo de ser excepcional. Quizas el unico caso muy claro es:
3. El encapsulamiento es bueno. Pero no con errores Los que mas detesto despues de los errores silenciosos son los que me distorcionan la realidad.
Y porque no? Y se me perdio el stack trace, que cada dia lo quiero mas. Y fallo en un punto mas alejado de donde esta el problema. Y como la mayoria de los componentes que uso tienen codigo, es mejor ver exactamente en donde dentro de todo eso paso. Ademas, esto supone que el programador sabe exactamente lo que fallo, y no estoy muy seguro de eso. Lo que me lleva a 4. Los mensajes de errores en español son tan indecifrables a los de ingles. Igual el usuario no lo va a entender. Cuando hablamos de un error, un real error, no existe manera de hacerlo claro. Es imposible. Igual da: "Acces violation 0x0000053566" que: "El programa ha referenciado una direccion de memoria invalida o que no existe, probablemente porque se referencio un objeto antes de crearse." No le veo la ventaja a lo segundo. Al principio, si la veia, pero ahora que aprendi a usar google prefiero los numeros hexadecimales porque me han sacado de mas de un lio. Y mientra mas raro e indecifrable es un error, mas facil es saber que esta pasando: Algo raro e indescifrable. Pero mensajes bonitos? Como los busco en google? Como va a ser mi unica forma de escribir un mensaje mejor que la peor manera de un error de MS que tiene cientos de referencias probadas por mucho tiempo por muchos programadores? En cambio, mi propio mensaje de error, hermoseado, no existe en Internet, nadie mas lo conoce, nadie mas puede ayudar. Quedo solo y aburrido. No confundamos con un mensaje normal: "El registro esta duplicado" No es un error. Es un programa que esta funcionando correctamente. Esto lleva a: 5. Solo hay que preocuparse por lo que es valido. Especialmente al hacer chequeos de datos. En vez de:
Es concentrarse en lo que necesito y solo chequear lo que necesito. Que estalle por todo lo demas. Si eso me molesta, entonces AUN el programa no es correcto. Una vez cubri los casos de uso, paro. 6. En la era moderna, hay correo, internet, archivos e imagenes. De un tiempo para aca no pierdo tiempo. Despues de que obligo al cliente a que me diga el mensaje de error (si lo hay) y me deletree en el peor espanglish posible (pero es mas facil para mi entender espanglish que para el lo que esta pasando) siempre pido un screenshot. Bingo. De muchas horas a pocas horas en tiempos de respuesta y solucion. Luego estan los logs, herramientas como madexpert, envio de errores a mi correo, etc... Al usuario solo se puede molestar con los pasos de reproduccion. |
Cita:
"Digame el error que le da:" Cita:
Casi mejor esto otro:"digame el código de error" Cita:
Saludos |
También hay que tener en cuenta la "teoría de la relatividad" :), todo es relativo, por ejemplo: ¿para qué quiere un mensaje de error el cliente de un cajero de banco?, ¿acaso cuando esté sacando dinero y le salga un fallo va a llamar al servicio técnico?, hay casos, como este, en los que no sirve de nada y es mejor "esconder" los errores.
Por supuesto, se debe mostrar al cliente algún mensaje amigable y simpático como: Cita:
|
Hola,
Bueeeeeeeeeeeeeeeeno. Lo cierto es que todo es relativo, así es la verdad. Peeeeeeeeeeeero, como norma general, creo que los errores no deben ocultarse ni al usuario ni a nadie, porque corres cierto riesgo de no enterarte al cabo de lo que está ocurriendo, vamos, digo yooooooooo. ;) Así que la norma general podría ser la de mostrar siempre los errores y, excepcionalmente, puede resultar apropiado no mostrarlos en modo alguno. |
Cita:
|
Hola,
Cita:
|
La franja horaria es GMT +2. Ahora son las 16:52:16. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi