不，它并未真正屏蔽异常，仅吞掉错误信息而未处理事务状态、游标等不一致问题，易导致数据错乱与逻辑隐蔽失败。
PL/SQL 里 EXCEPTION WHEN OTHERS THEN NULL 真的屏蔽了异常吗？
不，它只是吞掉了错误信息，但事务状态、游标、会话变量等可能已处于不一致状态。数据库没报错，不等于程序逻辑安全——这是最危险的错觉。
常见错误现象：INSERT 失败后后续 UPDATE 还在执行；批量处理中某条记录出错，整批结果却显示“成功”；调试时发现数据没写入，但日志里毫无异常痕迹。
- 它不会回滚当前事务（除非你显式写
ROLLBACK） - 不会重置
%NOTFOUND或%ROWCOUNT的语义上下文 - 在存储过程里被调用方完全感知不到内部已出错
什么时候能用 WHEN OTHERS THEN NULL？
仅限两类场景：明确知道错误可忽略，且副作用可控。比如清理临时表失败、尝试释放一个可能未持有的锁、读取非关键配置项时文件不存在。
使用场景示例：
BEGIN EXECUTE IMMEDIATE 'DROP TABLE temp_log'; EXCEPTION WHEN OTHERS THEN NULL; -- 表可能本来就没建，删不掉无所谓 END;
- 必须确保该操作是幂等的、无副作用的
- 不能出现在事务主干路径上（比如订单创建流程里删日志）
- 不能用于 DML 主体逻辑之后——否则你根本不知道
INSERT成没成功
WHEN OTHERS THEN NULL 的替代写法
真要忽略异常，得先确认错误类型，再精准捕获。盲目用 OTHERS 是偷懒，不是稳健。
推荐做法：
- 用具体异常名代替：
WHEN NO_DATA_FOUND THEN NULL、WHEN DUP_VAL_ON_INDEX THEN NULL - 记录日志再忽略：
WHEN OTHERS THEN logger.log_error(SQLCODE, SQLERRM); NULL - 加标记变量区分“预期忽略”和“意外失败”：
v_ignore_err := TRUE; ... EXCEPTION WHEN OTHERS THEN IF NOT v_ignore_err THEN RAISE; END IF;
参数差异：不同异常的 SQLCODE 值不同，NO_DATA_FOUND 是 +100，TOO_MANY_ROWS 是 -1422，硬写 OTHERS 就丢掉了这个区分能力。
为什么生产环境禁用裸 WHEN OTHERS THEN NULL？
它让问题隐身，把运行时错误转化成数据不一致、业务逻辑跳变、监控失灵这些更难定位的问题。
性能与兼容性影响很小，但维护成本爆炸：
- Oracle 12c+ 支持
DBMS_WARNING开启警告，但默认不报OTHERS THEN NULL这种写法 - 静态扫描工具（如 SonarQube、PL/SQL Cop）会直接标为 critical 级别问题
- 团队交接时，没人敢动这段逻辑——因为不知道它“本该失败”还是“不该失败”
真正复杂的是判断“哪些错误算可忽略”，这没法靠语法糖解决，得看业务契约。没想清楚这点就加 NULL，等于给代码埋雷。
