Bien que je convienne que 99 % du temps, il est déconseillé d'ignorer silencieusement les exceptions sans au moins les enregistrer quelque part, il existe des situations spécifiques où cela est parfaitement acceptable.
Dans ces situations, NULL est votre ami :
[...]
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
Voici deux situations typiques où ignorer les exceptions peut être souhaitable :
1) Votre code contient une instruction dont vous savez qu'elle échouera occasionnellement et vous ne voulez pas que ce fait interrompe le déroulement de votre programme. Dans ce cas, vous devez inclure votre instruction dans un bloc imbriqué, comme le montre l'exemple suivant :
CREATE OR REPLACE PROCEDURE MY_PROCEDURE()
IS
l_empoyee_name EMPLOYEES.EMPLOYEE_NAME%TYPE;
BEGIN
-- Catch potential NO_DATA_FOUND exception and continue
BEGIN
SELECT EMPLOYEE_NAME
INTO l_empoyee_name
FROM EMPLOYEES
WHERE EMPLOYEE_ID = 12345;
EXCEPTION
WHEN NO_DATA_FOUND THEN
NULL;
WHEN OTHERS THEN
RAISE;
END;
do_stuff();
EXCEPTION
WHEN OTHERS THEN
-- Propagate exception
RAISE;
END;
Notez que PL/SQL n'autorise généralement pas le type de gestion des exceptions On Error Resume Next connu de Visual Basic, où toutes les exceptions sont ignorées et le programme continue de s'exécuter comme si de rien n'était (voir En cas d'erreur reprendre le type suivant de gestion des erreurs dans PL /SQL Oracle ). Vous devez inclure explicitement les instructions potentiellement défaillantes dans un bloc imbriqué.
2) Votre procédure est si peu importante que le fait d'ignorer toutes les exceptions qu'elle génère n'affectera pas la logique de votre programme principal. (Cependant, c'est très rarement le cas et peut souvent entraîner un cauchemar de débogage à long terme)
BEGIN
do_stuff();
EXCEPTION
WHEN OTHERS THEN
-- Ignore all exceptions and return control to calling block
NULL;
END;