Anche se sono d'accordo sul fatto che il 99% delle volte è una cattiva pratica ignorare silenziosamente le eccezioni senza almeno registrarle da qualche parte, ci sono situazioni specifiche in cui ciò è perfettamente accettabile.
In queste situazioni, NULL è tuo amico:
[...]
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
Due situazioni tipiche in cui potrebbe essere auspicabile ignorare le eccezioni sono:
1) Il tuo codice contiene un'istruzione che sai fallirà occasionalmente e non vuoi che questo fatto interrompa il flusso del tuo programma. In questo caso, dovresti racchiudere la tua istruzione in un blocco nidificato, come mostra il seguente esempio:
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;
Si noti che PL/SQL generalmente non consente il tipo di gestione delle eccezioni On Error Resume Next noto da Visual Basic, in cui tutte le eccezioni vengono ignorate e il programma continua a essere eseguito come se nulla fosse (vedere In caso di errore, ripristina il tipo successivo di gestione degli errori in PL /Oracolo SQL ). Devi racchiudere in modo esplicito le istruzioni potenzialmente non riuscite in un blocco nidificato.
2) La tua procedura è così irrilevante che ignorare tutte le eccezioni che genera non influirà sulla logica del tuo programma principale. (Tuttavia, questo è molto raro e spesso può portare a un incubo di debug a lungo termine)
BEGIN
do_stuff();
EXCEPTION
WHEN OTHERS THEN
-- Ignore all exceptions and return control to calling block
NULL;
END;
