WHEN OTHERS THEN NULL 会彻底丢弃错误线索，导致事务异常中断、数据不一致且无法排查；必须用日志记录、重新抛出或显式忽略特定错误替代。
WHEN OTHERS THEN NULL 会让错误彻底消失
这不是“静默处理”，而是主动丢弃所有诊断线索。调用方收不到任何错误信号，事务可能中途中断但不回滚，下游逻辑继续执行却基于错误状态——比如库存扣减失败但订单仍生成。
常见现象包括：
- 存储过程返回成功，但实际数据未更新、未插入
- 日志表里查不到任何报错记录
-
SQLCODE和SQLERRM完全没被读取，堆栈信息丢失 - DBA 或开发排查时只能靠猜：是网络断了？权限没了？还是某条
UPDATE悄悄失败了？
PL/SQL 编译器会警告但很多人忽略它
启用警告后，ALTER SESSION SET plsql_warnings = 'enable:all'; 会在编译阶段就报 PLW-06009：
“OTHERS handler does not end in RAISE or RAISE_APPLICATION_ERROR”
这个警告只对存储过程/函数/包体生效，匿名块不触发——所以很多临时测试脚本里藏了这种写法，上线后才暴露问题。
关键点：
- 警告不是建议，是明确提示你：这个异常分支没有出口
- 它不依赖运行时触发，开发阶段就能发现，但需要主动开启并查看
SHOW ERRORS - 很多团队 CI 流程没集成该检查，导致带
NULL的WHEN OTHERS直接进生产
真正安全的替代写法只有三种
必须至少选其一，不能省略：
- 记录上下文：
DBMS_OUTPUT.PUT_LINE('Error ' || SQLCODE || ': ' || SQLERRM);（仅适合调试，生产环境请用日志表） - 写入持久日志：
INSERT INTO error_log (proc_name, err_code, err_msg, log_time) VALUES ('my_proc', SQLCODE, SQLERRM, SYSDATE); - 重新抛出：
RAISE;（保留原始堆栈）或RAISE_APPLICATION_ERROR(-20001, '业务失败: ' || SQLERRM);（带语义，便于上游识别）
如果真要忽略某个特定错误（比如 ORA-01403 在某些查询中是合法结果），必须显式判断并加注释：-- 忽略 NO_DATA_FOUND：该查询为空是正常业务路径，而不是笼统塞进 WHEN OTHERS。
WHEN OTHERS 不是兜底，而是最后一道防线
它捕获所有未被前面 WHEN 子句覆盖的异常，包括：
- 本该单独处理的预定义异常，如
TOO_MANY_ROWS、DUP_VAL_ON_INDEX - 系统级致命错误，如
ORA-00060（死锁）、ORA-01555（快照过旧） - 通过
PRAGMA EXCEPTION_INIT绑定的非预定义异常
把它们全塞进一个 WHEN OTHERS 分支，等于放弃语义区分。复杂业务中，死锁和空结果的应对策略天差地别，混在一起处理只会让问题更难定位。
最常被忽略的一点：异常处理不是写完就完事，而是要确保调用链上每一层都清楚自己该响应什么、该传递什么。WHEN OTHERS 的位置和内容，决定了整个调用栈的可观测性底线。
