Verificar si una imagen existe

[mamcx]

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:

Código Delphi [-]
try
  ..algo
except
  ..nada
end;

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:

Código Delphi [-]

if FileExist(....) then
begin
  OpenFile(...);
end;

Estoy siendo explicito en mi criterio: El codigo es valido solo si el archivo existe y de alli lo proceso. Pero

Código Delphi [-]

try
  OpenFile(...);
except
  ....
end;

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:

Código Delphi [-]
IncioTransaccion;
try
  Commit;
except
  abort;
  raise; //siempre dejo que mande el error original.
end;

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.

Código Delphi [-]
IniciarTransaccion;
try
 ....
 Commit;
except
  abort;
  show('No se pudo completar la operacion')
end;

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:

Código Delphi [-]

procedure AgregarCliente(....);
try
   ...uno
   ...dos
except
   if esto....
   if aquello...
   if lootro...
end;

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.

[[Lepe]]

Empezado por mamcx

obligo al cliente a que me diga el mensaje de error (si lo hay) y me deletree en el peor espanglish posible

... Por eso prefiero un código de error, el cliente ya tuvo que decirme por telefono el texto en inglés y aseguro que era peor escucharlo a él que a la cantante "tamara".


"Digame el error que le da:"

Network initialization Failed
Internal OS error opening \\servidor\....

"netuooorkkk initializ... espera mejor te lo deletreo Italia, Navarra Italia, Tarragona.."

Casi mejor esto otro:"digame el código de error"

No se ha podido abrir la Base de datos:
Categoría: BDE
Codigo de error:5466


Causa del error:
Network initialization Failed
Internal OS error opening \\servidor\....

Saludos

[Casimiro Noteví]

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:

Fecha/Hora: 28-12-2005 / 4:30am
Temperatura: -12º

Este terminal está fuera de servicio, vaya a sacar dinero al próximo más cercano que está en el quinto pino.
Perdone la molestias.

[dec]

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.

[Casimiro Noteví]

Empezado por dec

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.

En casos "normales", sí, tienes razón.

[dec]

Hola,

Empezado por Casimiro

En casos "normales", sí, tienes razón.

Pues ahora mismo me la quito de encima. La razón es a veces una cosa muy pesada que sirve de lastre más que nada.