No se si estoy entendiendo tu duda, ¿tu quieres capturar distintas excepciones/errores en el try? Si es eso debes hacer algo como esto:
try
HacerAlgo;
except
on E: Exception1 do
begin
// aqui el código sobre que hacer cuando se da Exception1
end; // fin para Exception1
on E: Exception2 do
begin
// aqui para el de Exception2
end; // fin para Exception2
// etc
end; // fin del try
// más código
Como condición necesaria, la última excepción que se debe poner es la más general: Exception. ¿Porqué? Porque el funcionamiento de la "búsqueda" y captura de excepciones se realiza recorriendo el árbol de herencia. Es decir, que debe enlistarse desde las excepciones más específicas hacia la más general; si tu pones únicamente o como primera excepción la de tipo E: Exception el programa detendrá en ella, independiente de la excepción puntual ya que es la más general. Para que te hagas una idea,
Si yo tuviera un árbol de herencia de excepciones así:
EErrorPerro -> EErrorCuadrupedo -> EErrorAnimal.
Y estoy interesado en capturar estas tres, debo ir desde el extremo de la hoja hacia el padre:
E: EErrorPerro
E: EErrorCuadrupedo
E: EErrorAnimal
Si pongo al reveés estoy diciendo algo como: "¿La excepción es del tipo EErrorAnimal? Naturalmente, cualquiera excepción por debajo de su rama la cumple: una EErrorPerro ES un tipo de ErrorAnimal, pero obviamente no necesariamente un EErrorAnimal será un EErrorPerro.
Cuando tu armes el listado de excepciones deberás definir conscientemente que excepciones pretenderás capturar y luego fijarte como se da la rama de herencia. Para todas aquellas que ya no tengas interés pero que consideres que se pueden presentar es válido poner la general: Exception. ¿Cómo te fijas? La fácil: escribiendo código forzando a que se la situación a esperar, tomar nota de la excepción y añadirla al código. Luego manteniendo presionado Ctrl haz clic en el nombre, te llevará hacia la su declaración y podrás "navegar" sobre la rama.
Casi todas las excepciones relacionadas con las bases de datos siguen una rama como esta: ErrorConcreto -> ErrordeSQL -> ErrorDeConexion -> EDataBase (o EDataBaseException, no recuerdo, es la más general de las definidas para el contexto de las ramas de bases de datos) -> Exception. No tengo a mano Lazarus ahora para fijarme.
En el caso de Zeos, creo que tiene su propio árbol de excepciones. Tendrías que fijarte.
Ahora bien, no es para nada sano deshabilitar las excepciones al nivel del compilador/IDE. ¿Porqué? Porque de esa forma no te enteras de los posibles errores que se pueden presentar... no siempre podemos estar optimistas de que nuestro código es 100% seguro. Es necesario que lo habilites. Si, te entiendo que sea un tanto molesto ver el "doble mensaje" pero es que uno es a nivel del IDE mientras se está desarrollando la aplicación y el otro es el propio que se va a presentar si se ejecuta la aplicación. Si no crees, prueba ejecutando el exe fuera del IDE. Ya no verás el "doble mensaje". Mientras estés en "tiempo de desarrollo" es muy útil tener activo el aviso de errores.
Las excepciones como su nombre lo indica son situaciones que no estaban esperadas en nuestra lógica para la aplicación. En ocasiones es útil mostrar al usuario de tales situaciones, como el ShowMessage o el MessageBox, y en otras es deseable (y viable) la posibilidad de detectar el problema puesto que podremos volvernos hacia atrás y dejar al sistema en "estado de normalidad".
También debes saber que el uso del try no se limita al Try-Except, existe justamente el Try-Finally. Y justamente está pensado este último para llevar al programa a estados de normalidad. En ocasiones es válido el primero y en otras el segundo; también es válido incluso "concatenar" ambos tipos.
try
// algo
try
// algo más
finally
// calmemos...
end;
except
// aqui podemos capturar exceptiones que se pueden dar dentro del try-finally
end;
Nuevamente te invito a leer la Cara Oculta de Delphi 4, si no recuerdo mal el capítulo 4 explica el tema de las excepciones.
Saludos,