when others会吞掉原始sqlcode和堆栈信息，导致仅见ora错误码而无法定位具体行号、调用链；必须在when others首行调用dbms_utility.format_error_backtrace才能获取完整错误上下文，且不可与raise连用。
WHEN OTHERS 会吞掉 SQLCODE 和堆栈信息
直接后果是：你只看到 ORA-00001 或 ORA-06502 这类通用码，但不知道它发生在哪一行、哪个子块、哪个嵌套调用里。PL/SQL 默认不保留错误上下文，WHEN OTHERS 捕获后若没主动记录，原始错误就被覆盖了。
常见错误现象：
– 存储过程静默失败，日志只写“出错了”
– 同一个 WHEN OTHERS 块反复触发，但每次 SQLCODE 都是 -1（内部错误）
– 调用链深层抛出的异常，在外层被 WHEN OTHERS 拦截后，DBMS_UTILITY.FORMAT_ERROR_BACKTRACE() 返回空或不完整
- 必须显式调用
DBMS_UTILITY.FORMAT_ERROR_BACKTRACE()才能拿到行号级堆栈，仅靠SQLERRM不够 -
SQLCODE在WHEN OTHERS中返回的是当前异常编号，不是原始异常；如果中间有 RAISE，原始码可能已丢失 - 嵌套块中发生异常，外层
WHEN OTHERS捕获时，SQLERRM可能是“ORA-06512: at line X”，但 X 指的是外层块的行号，不是出错点
WHEN OTHERS + COMMIT / ROLLBACK 导致事务状态混乱
很多人在 WHEN OTHERS 里无条件加 ROLLBACK，以为能兜底。但问题在于：异常发生时事务可能已部分提交（比如自治事务、外部 DML 已生效），或者根本没开启事务（如只读查询）。这时候强制回滚，反而破坏一致性。
使用场景：
– 存储过程含多个 INSERT/UPDATE，某条失败后想整体回滚
– 包含自治事务（PRAGMA AUTONOMOUS_TRANSACTION）的日志写入逻辑
– 调用链中上层已开始事务，本层只是子过程
- 不要在
WHEN OTHERS里默认写ROLLBACK；先用SELECT * FROM V$TRANSACTION或检查SQLCODE类型再决定 - 自治事务里的异常不能由外层
WHEN OTHERS捕获，它有自己的独立事务上下文 - 如果过程里混用 DML 和 SELECT INTO，
NO_DATA_FOUND不该触发回滚，但WHEN OTHERS会一并吃掉
WHEN OTHERS 掩盖预定义异常的语义差异
Oracle 预定义异常（如 NO_DATA_FOUND、TOO_MANY_ROWS）本身携带明确业务含义。一旦全扔进 WHEN OTHERS，你就失去了区分“查不到”和“查多条”的能力，后续逻辑只能靠猜。
参数差异：
– NO_DATA_FOUND：常用于校验前置条件，应返回空或默认值
– TOO_MANY_ROWS：通常是数据质量问题，需告警而非静默处理
– DUP_VAL_ON_INDEX：说明业务规则被违反，要反馈给调用方而非吞掉
- 永远优先捕获具体异常，
WHEN OTHERS只作兜底，且必须放在最后 - 同一个异常名在不同上下文含义不同：比如
VALUE_ERROR可能是类型转换失败，也可能是字符串截断，得结合SQLERRM内容判断 - 不要用
WHEN OTHERS THEN NULL—— 这是生产环境最危险的习惯之一
金仓等兼容库中 WHEN OTHERS 行为更不可靠
迁移至金仓数据库时，WHEN OTHERS 的实际表现可能和 Oracle 不一致：堆栈深度被截断、SQLCODE 映射错误、甚至某些预定义异常不触发。这不是 bug，而是兼容层对 PL/SQL 异常语义的简化实现。
性能 / 兼容性影响：
– 金仓对 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE() 支持有限，返回内容可能为空或格式错乱
– PRAGMA EXCEPTION_INIT 绑定非预定义异常时，在金仓中可能失效
– 自定义异常的传播路径在跨库调用时容易中断
- 迁移项目中，所有
WHEN OTHERS块必须重测，尤其关注错误日志是否完整、事务是否可回滚 - 避免依赖
SQLCODE = -1判断“未知错误”，金仓可能返回其他值 - 对关键业务逻辑，宁可用多个具体
WHEN分支，也不要图省事全塞进WHEN OTHERS
真实错误从来不在表面——它藏在被忽略的 SQLCODE 里、断掉的堆栈里、还有那个你以为“兜住了”的 WHEN OTHERS THEN NULL 后面。
