Q:

In what order do PL/SQL Exceptions get raised?

I'm trying to understand the order in which PL/SQL exceptions get raised. Here's my code using the HR schema:
DECLARE
  dept_to_delete departments.department_id%TYPE := 105;
  dept_to_keep departments.department_id%TYPE   := 115;

  integrity_constraint_violated EXCEPTION;
  PRAGMA EXCEPTION_INIT(integrity_constraint_violated, -2291);
  no_department_to_delete EXCEPTION;
BEGIN
  -- Will cause integrity_constraint_violated error
  UPDATE  employees
  SET     department_id = dept_to_keep
  WHERE   department_id = dept_to_delete;

  DELETE FROM departments
  WHERE department_id = dept_to_delete;
  IF SQL%NOTFOUND THEN
    RAISE no_department_to_delete;
  END IF;
EXCEPTION
  WHEN integrity_constraint_violated THEN
    DBMS_OUTPUT.PUT_LINE('Cannot assign employees to non-existing department.');
  WHEN no_department_to_delete THEN
    DBMS_OUTPUT.PUT_LINE('No such department to delete.');
END;

Neither department id 105 nor 115 exist in the departments table. My expectation was that the integrity_contraint_violated exception would be thrown first, because it occurs first in the code, but the user-defined no_department_to_delete gets thrown first. The output is:
Cannot assign employees to non-existing department.

Is there logic to this or is it just impossible to know which exception will be raised first?
EDIT
Jon Heller is right. The UPDATE statement is not causing an exception because the WHERE clause filters out all records. I messed with that for way too long. Anyway, the takeaway is that PL/SQL exceptions are raised depending on the order they occur, which is intuitive. Good to know. Thanks, Jon.

A:

PL/SQL exceptions are raised depending on the order they occur, not their order in the EXCEPTION clause.
The UPDATE statement must not be throwing an exception.  (If you're sure it is, then we can resolve if you modify the question with a minimal, reproducible example.
Also, not directly related to the question, but I recommend removing your custom exception handling.  It's not providing anything of value.  If there was no exception handling, the block would automatically raise the error message, object name, and line number, which is plenty of information to debug the problem.  With your custom exception handling, the object name and line number are not present.  And if DBMS_OUTPUT is not enabled the exception will not be seen.

