为何T-SQL遇错误不终止执行？TRY/CATCH与常规执行的差异疑问

1. 默认的T-SQL错误处理逻辑 #

和你熟悉的多数编程语言（出错即终止整个执行流程）不同，T-SQL的默认行为是：当遇到非致命错误（比如你遇到的级别16错误，这类错误属于用户可纠正的范畴）时，只会终止当前正在执行的单个语句（也就是EXEC spFoo），但不会终止整个**批次（Batch）**的执行。所以批次里后续的PRINT 'TEST'或其他操作会继续运行。

这里的核心是「批次」的概念：你写的EXEC spFoo PRINT 'TEST'本质是一个包含两个独立语句的批次（SQL Server会自动按语法拆分），每个语句都是独立的执行单元，单个语句的错误不会阻断批次内其他语句的执行——除非你主动修改这个逻辑。

2. TRY/CATCH块的特殊作用 #

BEGIN TRY...END TRY BEGIN CATCH...END CATCH是SQL Server 2005开始引入的结构化错误处理机制，它的核心设计就是改变默认的错误流程：一旦TRY块内的任意语句抛出错误，执行会立即跳转到CATCH块，TRY块中剩余的所有语句都会被跳过，不再执行。这就实现了你预期的「报错后停止执行」的效果，相当于用结构化逻辑覆盖了默认的批次错误处理规则。

3. 事务不改变默认行为的原因 #

即使把语句封装在事务中，默认情况下也不会影响这个行为——因为事务的核心职责是保证数据的一致性，而非控制批次的执行流程。如果你希望错误时终止批次并回滚事务，可以开启SET XACT_ABORT ON，这个选项会让SQL Server在遇到错误时立即终止批次并回滚事务，但这是可选配置，并非默认行为。

4. 这种“相悖”设计的初衷 #

T-SQL的这种设计最初是为了适配数据库批量操作的场景：比如DBA执行一个包含数十条更新语句的批次，其中某一条因数据问题报错，默认行为允许剩余的语句继续执行，而不是让整个批量任务彻底失败。这种「部分执行」的能力在数据库管理中非常实用，能避免因单个小错误导致大规模任务卡壳。

当然，这种设计也要求开发者手动处理错误场景，所以后来引入了TRY/CATCH，让你可以根据业务需求选择是用默认的「继续执行」还是「出错即停」的逻辑。

关于SQL CLR存储过程的补充 #

你提到存储过程关联SQL CLR，但这并不改变错误处理逻辑——SQL Server对错误级别的判断是统一的，级别16的错误无论来自原生T-SQL还是CLR，都会遵循默认的批次规则，只有TRY/CATCH能干预这个流程。

内容的提问来源于stack exchange，提问作者Philip Borgström