TRY-CATCH仅捕获严重性11–19的运行时错误，不捕获编译期错误（如表不存在、语法错误）、严重性≤10的RAISERROR、DDL语句错误及未设XACT_ABORT ON等情况；ERROR_*函数须在CATCH首行调用，事务需用XACT_STATE()判断后显式回滚。
TRY-CATCH 根本进不去，因为编译期错误不走运行时流程
SQL Server 的 TRY-CATCH 只对运行时错误生效，而语法类错误（比如拼错表名、漏写逗号、用错保留字）在存储过程创建或修改阶段就被编译器拦截了——压根不会生成可执行的执行计划，更不会进入 TRY 块。你看到的报错如 Invalid object name 'NonExistentTable' 或 Incorrect syntax near ','，都是在 CREATE PROCEDURE 或 ALTER PROCEDURE 执行时直接抛出的，CATCH 连影子都见不到。
常见误判场景：
- 在
TRY块里写SELECT * FROM nonexistent_table，结果建过程就失败，不是运行时报错 - 把
TRY-CATCH套在IF @flag = 1 BEGIN TRY ... END里，但TRY不在批处理顶层，SQL Server 直接拒绝解析 - 动态 SQL 中拼了未加
QUOTENAME()的表名，如@sql = 'SELECT * FROM ' + @tbl，哪怕@tbl是变量，编译器也会预检查并报错
DDL 语句出错会中断批处理，CATCH 来不及响应
CREATE TABLE、DROP INDEX 这类 DDL 在 SQL Server 中属于“批处理终结者”：一旦失败，整个批处理立即终止，后续语句（包括 CATCH 块）根本不会被读取。这不是 TRY-CATCH 没用，而是它没机会执行。
实操建议：
- 建表前先用
OBJECT_ID('table_name')检查是否存在，避免硬碰CREATE - 改用
IF NOT EXISTS (SELECT 1 FROM sys.tables WHERE name = 'xxx')包裹 DDL - 不要指望
TRY-CATCH拦住 DDL 错误；真要容错，得靠前置校验 + 显式控制流
RAISERROR 级别太低，看起来像“没捕获”
很多人写 RAISERROR('msg', 10, 1) 后发现进不了 CATCH，误以为机制失效。其实这是设计行为：RAISERROR 严重级别必须 ≥ 11 才触发 CATCH；级别 10 及以下是“信息性消息”，直接输出并继续执行。
对比示例：
-
RAISERROR('test', 10, 1)→ 控制台打印，不进CATCH -
RAISERROR('test', 11, 1)→ 进入CATCH，可被ERROR_MESSAGE()捕获 - 若需记录日志又不想中断流程，用
PRINT或写入表，别依赖RAISERROR级别 10
Oracle 和 MySQL 的“编译错误不可捕获”是共性，不是 SQL Server 特例
Oracle 存储过程中写错 END IF; 或漏掉分号，报 PLS-00103；MySQL 存储过程里用了 WITH 但版本低于 8.0，报 ERROR 1064——这些全在定义阶段失败，和 SQL Server 一样，任何运行时异常处理结构（EXCEPTION、HANDLER）都无能为力。
真正能做的只有两件事：
- 在
CREATE PROCEDURE前，用SET PARSEONLY ON（SQL Server）或SHOW ERRORS（Oracle）快速验证语法 - 把高风险逻辑（如对象名拼接、DDL）拆成独立脚本，人工或 CI 流水线中单独测试
编译期错误的本质是代码无法变成可执行单元，这时候谈“捕获”就像问“怎么在汽车发动前踩刹车”——引擎都还没转起来。
