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 内必须加LEAVE或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- 前缀的字符串，两者要一起存，单取一个容易定位失准。
