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 子句捕获的异常，包括：

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

• 本该被单独处理的预定义异常，比如 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 后面的代码，都得回答清楚：这个异常到这里就算完事了？还是只是换种方式继续传出去？