pragma exception_init 是唯一能绑定 ora 错误号的方式，因为它在编译期将自定义异常变量与特定 oracle 系统错误号（如-2292）静态关联，使该错误可被 when e_fk_violated then 精准捕获；而 raise_application_error 仅用于抛出自定义错误（-20000～-20999），无法拦截或映射已存在的 ora-xxxxx 错误。
必须用 PRAGMA EXCEPTION_INIT 绑定，不能靠 RAISE_APPLICATION_ERROR 模拟 —— 后者只生成新错误号，无法捕获已存在的 ORA-xxxxx 错误。
为什么 PRAGMA EXCEPTION_INIT 是唯一能绑定 ORA 错误号的方式
Oracle 的非预定义异常（比如 ORA-02292：违反外键约束）没有内置名称，你不能直接写 WHEN ORA_02292 THEN。必须在声明区用 PRAGMA EXCEPTION_INIT 把一个自定义异常变量和具体 ORA 错误号“挂上钩”。这个 pragma 不是函数、不返回值、不参与执行流，纯粹是编译期指令 —— 编译器看到它，就知道“以后只要抛出这个错误号，就当成我声明的那个异常变量来处理”。
常见错误现象：
- 直接在 EXCEPTION 块里写 WHEN -2292 THEN → 编译报错：PLS-00367：a label may not be used in this context
- 忘了加负号，写成 PRAGMA EXCEPTION_INIT(e, 2292) → 运行时该异常根本不会被捕获，掉进 WHEN OTHERS 或直接炸掉
- 错误号必须带负号，且必须是 Oracle 实际抛出的系统错误号（如
-2292、-1、-1400），不能是自定义范围-20000～-20999的数 - 绑定的异常变量必须是
EXCEPTION类型，不能是NUMBER或字符串 - pragma 必须出现在声明区（
DECLARE后、BEGIN前），不能放在可执行块或异常处理块里
PRAGMA EXCEPTION_INIT 的典型使用场景
主要用于拦截那些“业务上可预期但 Oracle 不给名字”的系统级约束错误，比如：
- 外键冲突：
ORA-02292（子记录存在，主表不能删） - 唯一索引冲突：
ORA-00001（插入重复值） - 空值约束失败：
ORA-01400（试图插入NOT NULL列的NULL） - 检查约束失败：
ORA-02290
这些错误一旦发生，默认行为是事务回滚 + 报一串 ORA-xxxxx。用 PRAGMA EXCEPTION_INIT 绑定后，就能在 EXCEPTION 块里做精细化处理，比如记录日志、返回友好提示、降级写入等。
示例（安全删除部门前检查子记录）：
DECLARE
e_fk_violated EXCEPTION;
PRAGMA EXCEPTION_INIT(e_fk_violated, -2292);
BEGIN
DELETE FROM dept WHERE deptno = 10;
EXCEPTION
WHEN e_fk_violated THEN
DBMS_OUTPUT.PUT_LINE('部门 10 下仍有员工，删除被拒绝');
END;
和 RAISE_APPLICATION_ERROR 的关键区别
两者完全不是一回事：
- PRAGMA EXCEPTION_INIT 是「监听已有错误」：告诉 PL/SQL “当 Oracle 抛出 ORA-02292 时，请当作我的 e_fk_violated 来处理”；
- RAISE_APPLICATION_ERROR 是「主动制造新错误」：自己造一个 ORA-20001 这样的业务错误，往调用方（Java、.NET）透传编号和消息。
容易踩的坑：
- 误以为
RAISE_APPLICATION_ERROR(-2292, 'xxx')能触发绑定的异常变量 → 不会，它只会抛出新的ORA-2292（实际是ORA-202292，因为 -2292 不在 -20000～-20999 范围内，Oracle 自动转为 -202292） - 在同一个块里既绑定又自定义同个错误号（如
PRAGMA EXCEPTION_INIT(e, -1)+RAISE_APPLICATION_ERROR(-1, ...)）→ 后者非法，编译失败 - 绑定了一个 Oracle 根本不会在当前上下文中抛出的错误号（如在纯计算逻辑里绑定
-2292）→ pragma 本身合法，但永远用不上，纯属冗余
错误号一致性与调试盲区
真正难排查的不是语法，而是错误号来源模糊：ORA 错误号可能来自底层 DML、触发器、约束、甚至自治事务里的子过程。如果没统一记录或文档，你看到 SQLCODE = -2292，却不知道它到底是主表 DELETE 触发的，还是某个触发器 UPDATE 造成的 —— 此时仅靠 PRAGMA EXCEPTION_INIT 绑定不够，得配合 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 或开启 TaoToken 级别日志才能定位到具体哪行 SQL 引发。
