必须用raise_application_error而非when others then raise，因后者会丢失原始错误上下文和错误码；正确做法是用raise_application_error(-20000~-20999, message, true)封装并透出异常。
WHEN OTHERS 不能直接 RAISE，必须用 RAISE_APPLICATION_ERROR 或显式 RAISE
很多人写 EXCEPTION WHEN OTHERS THEN RAISE;，以为能原样抛出原异常——实际在 PL/SQL 中，RAISE 单独出现时，**只在当前异常上下文中有效**；一旦离开 EXCEPTION 块，原异常上下文就丢失了。而 WHEN OTHERS 捕获后已脱离原始错误栈，此时 RAISE 会抛出一个空异常（PLS-00201 或不可预测行为），Java/JDBC 端收不到原始错误码。
真正安全的做法是：用 RAISE_APPLICATION_ERROR 封装错误信息，并传入自定义错误号（-20000 ~ -20999）：
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001, '步骤X执行失败: ' || SUBSTR(SQLERRM, 1, 200), TRUE);
-
TRUE表示把当前错误堆栈追加到原有堆栈中，对定位嵌套调用位置很关键 -
SUBSTR(SQLERRM, 1, 200)防止超长消息截断或报 ORA-20000（超出 2048 字节限制） - 不要省略第三个参数——缺省
FALSE会覆盖堆栈，丢失原始行号
捕获具体异常比 WHEN OTHERS 更可靠
Oracle 预定义了大量命名异常（如 NO_DATA_FOUND、TOO_MANY_ROWS、DUP_VAL_ON_INDEX），它们比 WHEN OTHERS 更精准，也避免掩盖真实问题。比如 SELECT ... INTO 失败时，NO_DATA_FOUND 和 TOO_MANY_ROWS 的语义远比数字错误码清晰。
常见误用是把所有逻辑塞进一个大块里，然后顶层只写 WHEN OTHERS。正确做法是分层处理：
BEGIN
SELECT ename INTO v_name FROM emp WHERE empno = p_id;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RAISE_APPLICATION_ERROR(-20002, '员工ID ' || p_id || ' 不存在');
WHEN TOO_MANY_ROWS THEN
RAISE_APPLICATION_ERROR(-20003, '员工ID ' || p_id || ' 对应多条记录');
END;
- 优先匹配命名异常，再补
WHEN OTHERS作兜底 - 对数据库约束类错误（如外键违例 ORA-02291），需用
PRAGMA EXCEPTION_INIT显式绑定 - 避免在过程最外层只留
WHEN OTHERS THEN NULL，这等于静默失败
SQLCODE 和 SQLERRM 只在 EXCEPTION 块内有效且易被覆盖
SQLCODE 和 SQLERRM 不是全局变量，它们的值只反映「最近一次触发的 SQL 或 PL/SQL 错误」，而且**一旦在 EXCEPTION 块中执行了任何可能出错的语句（比如 INSERT 日志表、调用 DBMS_OUTPUT），它们就会被新错误覆盖**。
典型陷阱：
EXCEPTION
WHEN OTHERS THEN
INSERT INTO log_table VALUES (SQLCODE, SQLERRM); -- 这里若日志表没权限，SQLCODE 就变成 ORA-01031
RAISE_APPLICATION_ERROR(-20001, SQLERRM); -- 此时 SQLERRM 已不是原始错误
- 务必在 EXCEPTION 块开头就缓存这两个值：
v_code := SQLCODE; v_msg := SQLERRM; - 日志写入操作建议用自治事务（
PRAGMA AUTONOMOUS_TRANSACTION），避免受主事务回滚影响 -
DBMS_UTILITY.FORMAT_ERROR_BACKTRACE()比SQLERRM更准，它返回真实出错行号，不是 EXCEPTION 块所在行
Java 调用端能否收到异常，取决于是否真的“抛出”
很多存储过程写了 EXCEPTION 块并记录日志，但最后只 RETURN 或什么都不做——这会让 JDBC 认为执行成功，后续语句仍复用同一条连接，可能引发 ORA-01013 等残留状态错误。
要让 Java 端 catch (SQLException e) 捕获到，必须满足两个条件：
- 存储过程中断执行流，不返回正常控制权（即不能靠
RETURN结束） - 使用
RAISE_APPLICATION_ERROR或RAISE（针对已声明异常），触发 PL/SQL 异常传播机制 - 错误号必须在 -20000 ~ -20999 范围内，否则 JDBC 可能解析失败
Java 侧可直接检查：e.getErrorCode() == -20001，比解析 e.getMessage() 更稳定。
最易被忽略的一点：异常处理不是“写完就算”，而是要确保错误被传播出去——吞掉、静默、仅记录却不中断，都等于没处理。
