SQL存储过程如何统一处理业务异常-SQL-PHP中文网

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

sql存储过程如何统一处理业务异常

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 内必须加 LEAVE 或 ITERATE，不能依赖“执行完就停”
别混用错误码：SQLSTATE 'HY000' 太宽泛，可能把死锁（1205）和权限拒绝（1045）一锅端；优先用具体 SQLSTATE，或至少区分判断 MYSQL_ERRNO