SQL Server中TRY…CATCH仅捕获运行时错误（如主键冲突、类型转换失败），不捕获编译期错误（如表不存在、语法错误），后者在存储过程创建时即报错，根本不会执行到TRY块；RAISERROR需≥11级才触发CATCH。

SQL Server 里 TRY…CATCH 捕不到业务错误？先确认是不是运行时错误

TRY…CATCH 只捕获运行时错误（比如 INSERT 违反主键、CONVERT 类型失败），不捕获编译期错误（如表名写错、语法拼错）。这类错误在 CREATE PROCEDURE 阶段就报错，根本不会执行到 BEGIN TRY 里。

常见误判场景：

• 你写了 BEGIN TRY SELECT * FROM NonExistentTable END TRY，结果创建存储过程就失败——不是 TRY 没用，是这句压根没机会跑
• 想靠 TRY 捕获 RAISERROR 抛出的业务提示，但严重级设成了 10（信息级），它不会进 CATCH；必须 ≥11 才触发
• DDL 语句（如 CREATE TABLE）出错可能直接中断批处理，CATCH 来不及响应

真正适合放进 TRY 块的，是明确可能失败的 DML 或函数调用，比如带约束检查的插入、动态 SQL 执行、或调用外部函数。

PostgreSQL 的 EXCEPTION 块为什么总漏掉上下文？

PL/pgSQL 的 BEGIN ... EXCEPTION ... END 必须写在函数体内部，不能用于 DO 块或纯 SQL 存储过程。更关键的是：它只按 SQLSTATE 码精确匹配，不支持通配符。

实操要点：

• 别写 WHEN OTHERS THEN 后直接 RETURN——错误堆栈全丢，连哪行出的问题都不知道
• 必须用 GET STACKED DIAGNOSTICS 拿位置信息，例如：v_line := pg_exception_context;
• 常用 SQLSTATE 码要记牢：'23505'（唯一冲突）、'42703'（列不存在）、'P0001'（RAISE EXCEPTION 自定义）
• INSERT ... ON CONFLICT 这种原生语法比靠异常捕获快一个数量级，优先用它处理已知冲突场景

MySQL 的 DECLARE HANDLER 为什么“处理了却像没处理”？

MySQL 的异常处理器默认走的是 CONTINUE 逻辑。说白了，一旦 handler 被触发，后面的语句并不会停下来，还是会接着执行——这恰恰是最容易踩中的坑。比如写了 DECLARE CONTINUE HANDLER FOR SQLEXCEPTION，又在 handler 里做了 ROLLBACK，看上去像是把异常兜住了，但问题在于，handler 跑完之后，下一行 INSERT 依旧会继续执行，这时候事务状态往往已经乱了。

必须显式控制流程：

• 严重错误一律用 DECLARE EXIT HANDLER，确保进入 handler 后立即退出当前作用域
• 若要用 CONTINUE，handler 内必须加 LEA VE 或 ITERATE，不能依赖“执行完就停”
• 别混用错误码：SQLSTATE 'HY000' 太宽泛，可能把死锁（1205）和权限拒绝（1045）一锅端；优先用具体 SQLSTATE，或至少区分判断 MYSQL_ERRNO

Oracle 里只写 DBMS_OUTPUT.PUT_LINE 就等于没处理异常

DBMS_OUTPUT.PUT_LINE 输出的内容只到客户端缓冲区，调用方收不到任何错误信号，事务也不会自动回滚——表面看“执行成功”，实际数据已损坏。

正确链路是三步闭环：

• 用自治事务写日志（PRAGMA AUTONOMOUS_TRANSACTION），确保日志落地不被主事务回滚影响
• 调用 RAISE_APPLICATION_ERROR(-20001, 'xxx') 中断执行，并向调用方传递标准错误号
• 若需忽略特定错误（如 ORA-00955 对象已存在），必须在 WHEN OTHERS 里显式判断 SQLCODE，而不是无条件吞掉

注意：SQLCODE 是数值（如 -1），SQLERRM 是带 ORA- 前缀的字符串，两者要一起存，单取一个容易定位失准。

《夸克》非常好用的免费AI浏览器

下载APP查看