Antes de nada definimos nuestros tipos de Excepciones.
Después solo tenemos que crearlas y lanzarlas cuando más nos apetezcaa con
raise NOMbreExcepcion.Create(mensaje a mostrar)
Por último en un TApplictionEvents, en su evento OnException, averiguamos que tipo de excepción es y actuamos en consecuencia, grabando un archivo .txt la clase de excepción y la descripción.
Código Delphi
[-]
type EShowException = class Exception;
EFatalException = class Exception;
EHiddenException = Class Exception;
procedure TDm.IBDatosBeforeConnect(Sender: TObject);
var
sPath: string;
begin
sPath := 'E:\bddsistemas\DatosSanignacio\colacion.GDB';
if not FileExists(sPath) then
begin
raise EFatalException.Create ('No se encuentra la base de datos '+sPath+' por lo tanto finalizará la sesión');
end;
IBDatos.DatabaseName := sPath;
end;
procedure TFormPrincipal.ApplicationEventsOnException(....E:Exception);
begin
GrabarAArchivoLog(E.ClassName, E.Message);
if E is EFatalException then
begin
ShowMessage E.message);
Application.Terminate;
end
else if E is EShowException then
ShowMessage(E.Message);
else if E is EHideException then
end;
El tema de EHideException es muy subjetivo, yo lo uso con aquellos fallos tontos y que suelo controlar como '' is not a valid integer, la fecha introducida no es válida, etc. En esos casos suelo mostrar un mensaje al usuario dándole ayuda en español, pero aparte, suelo lanzar la excepción para:
- Que se corte el flujo normal del programa y no ejecute código con una fecha inválida
- Que se guarde la excepción en el archivo de texto, para cuando vaya a modificar algo, ver los tipos de errores que suele cometer el usuario.
En delphi 6, cuando se lanza una excepción siempre se muestra al usuario, aunque tengamos un TApplicationEvents.
En BDS 2006, cuando se lanza una excepción y existe el TApplicationEvents.OnException, la excepción no se muestra al usuario final, por ello, he puesto ShowMessages dentro de dicho manejador.
La forma de mostrar la excepción al usuario, ya es estilo propio, ShowMessage, MessageBox, etc.;
Edito:
Los try ... except se deberían poner donde quiera que pueda producirse un error, pero claro, son muchos puntos en una aplicación mediana, por tanto, puedes controlar algunos directo en el código, y el resto en el ApplicationEvents.OnException.
El flujo normal de excepciones es:
- Se produce una excepción, si está entre un try ... except:
Se salta directamente a ese except y se ejecutan las líneas que haya, después se continúa en al final del except....end.
Si dentro del except..ende hay una instrucción raise;, la misma excepción que ha saltado, se vuelve a lanzar, si hay un ApplicationEvents, llegará hasta él.
- Se produce una excepción, no hay ni try...except ni tampoco un ApplicationEvents:
Se corta el flujo del programa en esa línea de código y se muestra al usuario el mensaje de la excepción.
Saludos