在Oracle的PL/SQL开发中，预定义异常只能覆盖NO_DATA_FOUND、TOO_MANY_ROWS等数据库内部错误。当业务规则被破坏时，例如账户余额不足、审批状态不允许更新、参数超出合理区间，数据库本身不会主动报错，必须由开发者在代码中显式抛出异常。自定义异常的本质就是给业务错误一个可识别的名称和错误码，让错误不仅能被当前块处理，也能稳定地传递给外层调用者。
一、声明自定义异常并用RAISE抛出
在PL/SQL的声明部分，可以像声明变量一样声明一个用户自定义异常。异常名称只是一个标识符，不代表任何数据库错误码。声明完成后，配合RAISE语句即可在业务条件不满足时中断当前执行流程，转入异常处理区域。
DECLARE
e_balance_not_enough EXCEPTION;
v_balance NUMBER(10,2);
BEGIN
SELECT balance INTO v_balance FROM accounts WHERE account_id = 100;
IF v_balance < 1000 THEN
RAISE e_balance_not_enough;
END IF;
DBMS_OUTPUT.PUT_LINE('交易处理中');
EXCEPTION
WHEN e_balance_not_enough THEN
DBMS_OUTPUT.PUT_LINE('余额不足，无法完成交易');
END;
上面的代码中，e_balance_not_enough只作用于当前普通块。如果余额小于1000，RAISE语句会立即中断BEGIN到EXCEPTION之间的剩余逻辑，跳转到对应的WHEN分支执行处理。如果当前块没有捕获该异常，异常会继续向外层块传播，直到被处理或返回给客户端。
需要特别注意的是，直接使用RAISE抛出的用户自定义异常不会自动附加ORA错误码。调用者通过SQLCODE读取错误码时，返回的是正整数1；通过SQLERRM读取错误消息时，返回的是User-Defined Exception。这种情况更适合作为块内部的控制流信号，不适合直接作为面向客户端或调用方的业务错误。如果希望返回结构化错误码和清晰消息，应当结合RAISE_APPLICATION_ERROR或PRAGMA EXCEPTION_INIT一起使用。
二、使用RAISE_APPLICATION_ERROR返回可读错误消息
RAISE_APPLICATION_ERROR是Oracle提供的过程，用于向调用方抛出自定义错误号和错误消息。它的错误号范围被限制在-20000到-20999之间，这个区间专门留给应用程序使用，可以避免与Oracle内置错误码冲突。调用该过程后，错误会立即抛出，后续语句不会继续执行。
CREATE OR REPLACE PROCEDURE update_salary(p_emp_id NUMBER, p_pct NUMBER) IS
BEGIN
IF p_pct > 0.5 THEN
RAISE_APPLICATION_ERROR(-20001, '加薪比例不能超过50%');
END IF;
UPDATE employees SET salary = salary * (1 + p_pct) WHERE employee_id = p_emp_id;
END;
调用方可以像捕获普通ORA错误一样捕获这个自定义错误。常见的做法是在WHEN OTHERS分支中比较SQLCODE的值，如果等于-20001，说明业务参数校验失败，可以给出友好提示；如果是其他错误，则继续向上一层抛出，避免掩盖未预期的数据库问题。
BEGIN
update_salary(100, 0.6);
EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -20001 THEN
DBMS_OUTPUT.PUT_LINE('业务错误：' || SQLERRM);
ELSE
RAISE;
END IF;
END;
与直接RAISE自定义异常相比，RAISE_APPLICATION_ERROR会把错误码和消息写入错误栈，调用方通过SQLCODE、SQLERRM可以拿到稳定的错误信息。前端应用可以直接解析ORA-20001后面的消息文本，从而把数据库层的业务校验失败转换成界面上的可读提示。它的第三个参数keep_errors可以控制是否保留原有的错误栈，默认值为FALSE，表示只保留当前自定义错误信息。
三、PRAGMA EXCEPTION_INIT绑定错误号
如果希望用异常名称而不是错误号来捕获RAISE_APPLICATION_ERROR抛出的错误，可以在声明部分使用编译指示PRAGMA EXCEPTION_INIT，把一个自定义异常名称绑定到指定的错误码。这样处理后，WHEN子句就可以直接使用异常名称，代码的可读性会明显提高。
DECLARE
e_salary_limit EXCEPTION;
PRAGMA EXCEPTION_INIT(e_salary_limit, -20001);
BEGIN
BEGIN
RAISE_APPLICATION_ERROR(-20001, '工资超出上限');
EXCEPTION
WHEN e_salary_limit THEN
DBMS_OUTPUT.PUT_LINE('捕获到工资上限异常');
END;
END;
PRAGMA EXCEPTION_INIT本质上是编译期绑定，它告诉Oracle：当出现-20001这个错误码时，把它识别为e_salary_limit异常。因此，无论错误来自RAISE_APPLICATION_ERROR，还是来自数据库内部，只要错误码一致，都可以被同一个WHEN分支捕获。这种方式也常用于绑定Oracle内置错误号，例如把违反外键约束的ORA-02292错误绑定为e_fk_violation，从而在异常处理区用名称而不是数字来描述错误。
在实际项目中，推荐的做法是在包规范中统一定义公共异常名称，并在包体中通过PRAGMA EXCEPTION_INIT绑定-20000到-20999之间的业务错误码。这样所有存储过程共享一套异常命名，调用方不需要记住每个错误码的具体含义，只需要按异常名称捕获即可。
四、嵌套块中的异常传播与捕获策略
PL/SQL异常处理遵循就近匹配原则：异常发生后，先查找当前块的EXCEPTION部分，如果找到匹配的WHEN分支，则执行对应逻辑；如果当前块没有匹配分支，则终止当前块并把异常抛给外层块继续处理。利用这一特性，可以通过嵌套块实现局部容错。内层块捕获并处理可恢复的异常，未处理的异常继续向外传播，由外层统一兜底。
DECLARE
e_fatal EXCEPTION;
BEGIN
BEGIN
RAISE e_fatal;
EXCEPTION
WHEN NO_DATA_FOUND THEN
NULL;
END;
EXCEPTION
WHEN e_fatal THEN
DBMS_OUTPUT.PUT_LINE('外层捕获到致命异常');
END;
上述代码中，内层块的EXCEPTION只捕获NO_DATA_FOUND，而e_fatal没有对应的WHEN分支，因此异常会向外层传播，最终被外层的WHEN e_fatal捕获。这种结构非常适合分批处理数据：内层块单条记录失败时只记录日志并继续处理下一条，外层块统一处理整体失败、事务回滚等逻辑。
生产环境中必须避免WHEN OTHERS THEN NULL这种写法，它会直接吞掉所有异常，导致业务看起来执行成功，实际上数据可能已经不一致。合理的兜底做法是记录SQLCODE、SQLERRM以及错误发生位置，然后再决定是否重抛。Oracle提供DBMS_UTILITY.FORMAT_ERROR_BACKTRACE函数，可以返回出错位置的调用堆栈，对定位问题非常有帮助。
EXCEPTION
WHEN OTHERS THEN
INSERT INTO error_log(err_code, err_msg, backtrace, created_at)
VALUES (SQLCODE, SQLERRM, DBMS_UTILITY.FORMAT_ERROR_BACKTRACE, SYSDATE);
RAISE;
END;
把异常信息写入日志表后再执行RAISE，可以在不丢失错误上下文的情况下，让上层调用者仍然感知到异常发生。这样既能保留完整的问题追踪链路，又能保持存储过程调用接口的错误可见性。自定义异常的抛出与捕获并不是为了掩盖错误，而是为了让错误信息更准确地反映业务语义。
自定义异常的抛出与捕获是Oracle PL/SQL错误处理的核心能力。通过声明EXCEPTION变量、使用RAISE主动抛出、用PRAGMA EXCEPTION_INIT绑定错误码、再用RAISE_APPLICATION_ERROR返回可读消息，可以构建一套稳定且清晰的错误处理体系。实际开发中建议统一错误号段和消息格式，避免在存储过程中随意抛出未被文档化的错误。配合嵌套块传播规则和错误日志记录，能够显著提升数据库程序的可维护性和排错效率。
Oracle自定义异常PL/SQL异常处理RAISE_APPLICATION_ERROR修改时间：2026-08-26 22:49:58