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?
Cita:
|
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?"
Código:
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