WHEN OTHERS 并非“吞掉”异常，而是捕获后若未显式处理（如记录日志、RAISE或RAISE_APPLICATION_ERROR），则错误静默消失；必须至少记录SQLERRM或重新抛出以保障可追溯性。
WHEN OTHERS 不是“吞掉”异常，而是捕获后默认不做任何处理——如果你没写日志、没 RAISE、也没调用 RAISE_APPLICATION_ERROR，异常就静默消失了。
WHEN OTHERS 后只写 NULL 就等于丢弃错误
这是最常见也最危险的写法：
EXCEPTION
WHEN OTHERS THEN
NULL; -- ⚠️ 错误被彻底抹掉，调用方收不到任何信号- 程序表面不报错，但实际逻辑中断、数据未提交、下游依赖失败
- 日志里查不到痕迹，
SQLCODE和SQLERRM都没被读取，等于主动放弃诊断线索 - PL/SQL 编译器会警告：PLW-06009（如知识库中所示），提示 “OTHERS handler does not end in RAISE or RAISE_APPLICATION_ERROR”
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, 'Custom msg: ' || SQLERRM);（带业务语义） - 如果真要静默处理，必须加注释说明原因，例如：“此处忽略 ORA-01403 因为空数据是合法业务状态”
为什么不能依赖 WHEN OTHERS 做兜底？
它匹配所有未被前面 WHEN 子句捕获的异常，包括：
- 本该被单独处理的预定义异常，比如
NO_DATA_FOUND或TOO_MANY_ROWS—— 放到WHEN OTHERS里就失去语义区分 - 本该由调用方处理的系统级错误，如
ORA-00060（死锁）或ORA-01555（快照过旧） - 自定义异常和非预定义异常（通过
PRAGMA EXCEPTION_INIT绑定的）也会被一并捕获，掩盖真实意图
真正健壮的做法是：先列明已知需特殊响应的异常（如 WHEN DUP_VAL_ON_INDEX THEN ...），再用 WHEN OTHERS 做最后防线——且必须留痕、必须决定是否向上抛。
编译期就能发现 WHEN OTHERS 风险
启用 PL/SQL 警告能提前暴露问题：
ALTER SESSION SET plsql_warnings = 'enable:all';
- 执行后运行
SHOW ERRORS，若出现 PLW-06009，说明WHEN OTHERS分支没以RAISE或RAISE_APPLICATION_ERROR结尾 - 这个检查不依赖运行时触发，开发阶段就能堵住静默失败漏洞
- 注意：仅对存储过程/函数/包体生效，匿名块不会触发该警告
关键不是禁用 WHEN OTHERS，而是让它不成为错误隐身衣——每一条 WHEN OTHERS 后面的代码，都得回答清楚：这个异常到这里就算完事了？还是只是换种方式继续传出去？
