要知道，SQL Server 的 TRY...CATCH 机制并非万能——它只能捕获严重级别 11–19 的运行时错误。编译期错误（例如语法错误、对象不存在）、严重级别 20+ 的致命错误（如连接中断），以及 RAISERROR 级别 10 及以下的提示性消息，均无法被其捕获。因此，在编写健壮的错误处理逻辑时，必须配合 XACT_STATE() 判断事务状态、利用 ERROR_* 函数获取上下文信息，同时还需警惕 CATCH 块内二次错误的产生。
TRY...CATCH在SQL Server中是否能捕获所有错误？
许多 SQL Server 开发者常误以为将代码放入 TRY 块便可高枕无忧，实则不然。举例来说，执行 SELECT * FROM NonExistentTable 这类语法正确但对象不存在的语句，在编译阶段就会报错，根本不会进入 TRY 块。而 RAISERROR('msg', 10, 1) 这类低级别消息同样不会触发 CATCH——必须使用 RAISERROR('msg', 11, 1) 或更高级别才能生效。
如何在存储过程中正确嵌套事务与TRY...CATCH？
关键在于检查事务的当前状态，不能直接执行 COMMIT 或 ROLLBACK。SQL Server 提供的 XACT_STATE() 函数可帮助判断：返回 1 表示事务可提交，-1 表示必须回滚，0 则无活动事务。具体做法如下：
- 在
CATCH块开头立即调用XACT_STATE()，避免依赖@@TRANCOUNT（该变量不可靠）。 - 若结果为
-1，必须执行ROLLBACK，否则后续语句均会失败。 - 若结果为
1，可根据业务逻辑选择COMMIT或ROLLBACK。 - 最后务必使用
THROW重新抛出错误（SQL Server 2012+ 支持），以保留原始错误号和行号。
BEGIN TRY BEGIN TRANSACTION; UPDATE Accounts SET Balance -= @amount WHERE ID = @accountID; UPDATE Accounts SET Balance += @amount WHERE ID = @targetID; COMMIT TRANSACTION;END TRYBEGIN CATCH IF XACT_STATE() <> 0 ROLLBACK TRANSACTION; THROW; -- 保留原始错误上下文END CATCH
为什么CATCH块里不能直接用@@ERROR获取错误号？
@@ERROR 仅反映上一条语句的错误号，而 CATCH 块中的第一条语句（如 DECLARE）会立即将其覆盖。正确做法是使用 ERROR_NUMBER() 等内置错误函数，它们在 CATCH 作用域内稳定返回本次错误信息。具体函数包括：
ERROR_NUMBER()→ 替代@@ERRORERROR_SEVERITY()→ 获取错误严重级别ERROR_LINE()→ 精准定位TRY块内出错的代码行号ERROR_MESSAGE()→ 提供比@@ERROR更完整的错误描述- 注意：这些函数在
CATCH块外调用会返回NULL，不能跨作用域缓存使用。
日志记录时要注意哪些隐式转换陷阱？
将错误信息写入日志表时，常见陷阱是数据类型不匹配。ERROR_MESSAGE() 返回 nvarchar(4000)，若日志字段定义为 varchar(500)，SQL Server 会静默截断——既不报错也不给出警告。因此：
- 日志表字段类型需保持一致：建议使用
nvarchar(max)或至少nvarchar(4000) - 拼接字符串时优先使用
CONCAT函数，相比+和CAST更安全，可避免隐式转换 - 避免在
CATCH块中调用可能失败的复杂逻辑（如远程查询、链接服务器），否则原始错误信息可能被掩盖
健壮的错误处理真正困难之处不在于结构，而在于意识到 TRY...CATCH 存在固有边界——它无法处理编译错误、连接中断或资源耗尽，而这些恰恰是生产环境中最为常见的故障根源。
