SQLServer异常处理全解析

### SQL Server 异常处理全解析 #### 1. 特定异常路径编码 在 SQL Server 中，一些函数（尤其是 `ERROR_NUMBER`）允许为特定异常编写特定的处理路径。例如，若开发者知道某段代码可能会引发一个可通过编程修复的异常，就可以在 `CATCH` 块中检查该异常编号。 #### 2. 异常重抛 多数具备 `try/catch` 功能的语言都支持从 `catch` 块中重抛异常。这意味着原本在 `try` 块中发生的异常会再次被抛出，就好像它从未被处理过一样。当你需要对异常进行一些处理，同时又要让调用者知道例程中出现问题时，这种方法很有用。 T-SQL 本身没有内置的重抛功能，但结合 `CATCH` 块的错误函数和 `RAISERROR` 可以轻松实现。以下是一个基本示例： ```sql BEGIN TRY SELECT CONVERT(int, 'ABC') AS ConvertException; END TRY BEGIN CATCH DECLARE @ERROR_SEVERITY int = ERROR_SEVERITY(), @ERROR_STATE int = ERROR_STATE(), @ERROR_NUMBER int = ERROR_NUMBER(), @ERROR_LINE int = ERROR_LINE(), @ERROR_MESSAGE varchar(245) = ERROR_MESSAGE(); RAISERROR('Msg %d, Line %d: %s', @ERROR_SEVERITY, @ERROR_STATE, @ERROR_NUMBER, @ERROR_LINE, @ERROR_MESSAGE); END CATCH GO ``` 由于 `RAISERROR` 不能用于抛出编号低于 13000 的异常，在这种情况下“重抛”异常需要引发一个用户定义的异常，并通过特殊格式的错误消息返回数据。因为 `RAISERROR` 调用中不允许使用函数，所以在调用 `RAISERROR` 重抛异常之前，需要先定义变量并赋值。上述 T-SQL 的输出如下： ``` (0 row(s) affected) Msg 50000, Level 16, State 1, Line 19 Msg 245, Line 2: Conversion failed when converting the varchar value 'ABC' to data type int. ``` 需要注意的是，根据接口需求，你可能并不总是想重抛最初捕获的异常。在很多情况下，捕获初始异常，然后抛出一个对调用者更相关（或更有帮助）的新异常可能更有意义。例如，在使用链接服务器时，如果服务器因某种原因无响应，代码会抛出超时异常。此时，返回一个通用的“数据不可用”异常，而不是向调用者暴露问题的实际原因，可能更合适。这需要根据具体情况来决定，以设计出最优的存储过程接口。 #### 3. TRY/CATCH 的使用场景 在 T-SQL 例程（如存储过程）中处理异常的一般用例是尽可能在底层封装异常，以简化应用程序的整体代码。例如，数据库异常日志记录。与其将无法正确处理的异常返回给应用程序层，再从应用程序层将其记录回数据库，不如在数据库例程范围内直接记录。 另一个用例涉及对应用程序代码问题的临时修复。例如，由于应用程序的一个 bug，可能偶尔会将无效键传递给一个本应将其插入表中的存储过程。此时，在数据库中捕获异常，而不是将其抛回给应用程序让用户收到错误消息，可能是一个简单的临时“修复”方法。这种快速修复通常比重新构建和重新部署整个应用程序成本低得多。 不过，也要注意不要过度封装异常。确保不要过度处理安全问题、严重的数据错误以及其他应用程序（最终是用户）应该知晓的异常。过度的异常处理可能会隐藏问题，直到问题严重到无法忽视。长期隐藏在异常处理程序背后的问题通常会以无法修复的数据损坏形式暴露出来，这种情况往往由于缺乏有效的备份而变得更加严重，最终可能导致业务损失，开发者也可能需要更新简历寻找新工作。避免这个问题其实很简单，只需运用一些常识，不要为了抑制所有异常而走向极端。 #### 4. 使用 TRY/CATCH 构建重试逻辑 在处理死锁时，`TRY/CATCH` 可以用于完全封装异常。虽然最好是找到并解决死锁的根源，但这通常是一项困难且耗时的任务。因此，常见的做法（至少是临时的）是让应用程序重新发出导致死锁的请求。最终，死锁条件会自行解决（即另一个事务完成时），DML 操作将按预期执行。但需要注意的是，这不是解决反复出现的死锁问题的长期解决方案。 通过使用 T-SQL 的 `TRY/CATCH` 语法，应用程序不再需要重新发出请求，甚至不需要知道发生了问题。可以设置一个重试循环，在 `TRY` 块中尝试容易发生死锁的代码，在 `CATCH` 块中捕获死锁并再次尝试。以下是一个基本的重试循环实现： ```sql DECLARE @Retries int; SET @Retries = 3; WHILE @Retries > 0 BEGIN BEGIN TRY /* Put deadlock-prone code here */ --If execution gets here, success BREAK; END TRY BEGIN CATCH IF ERROR_NUMBER() = 1205 BEGIN SET @Retries = @Retries - 1; IF @Retries = 0 RAISERROR('Could not complete transaction!', 16, 1); END ELSE RAISERROR('Non-deadlock condition encountered', 16, 1); BREAK; END CATCH END; GO ``` 在这个示例中，容易发生死锁的代码会根据 `@Retries` 的值进行多次重试。每次循环都会尝试执行代码。如果代码成功执行且没有抛出异常，会执行 `BREAK` 语句，循环结束。否则，执行会跳转到 `CATCH` 块，检查错误编号是否为 1205（死锁受害者）。如果是，则减少计数器的值，以便再次尝试循环。如果异常不是死锁，则抛出另一个异常，让调用者知道出现了问题。确保错误的异常不会触发重试是很重要的。 #### 5. 异常处理与防御性编程 异常处理非常有用，在 T-SQL 中更是如此。但要记住，异常处理不能替代在错误发生前对错误条件进行适当检查。只要有可能，就应该进行防御性编码，主动寻找问题，如果能检测并处理这些问题，就编写相应的代码。 一般来说，处理异常比处理错误更好。如果在开发过程中能预测到某种情况并编写处理代码路径，通常会比在异常发生后再捕获和处理它提供更健壮的解决方案。 #### 6. 异常处理与 SQLCLR .NET Framework 有自己的异常处理机制，与 T-SQL 处理异常的机制完全不同。那么，当在 SQL Server 托管的 SQLCLR 进程中执行的 CLR 代码发生异常时，这两个系统是如何交互的呢？ 来看一个示例，以下 C# 代码展示了一个简单的 CLR 用户定义函数（UDF），用于将一个数除以另一个数： ```csharp [Microsoft.SqlServer.Server.SqlFunction()] public static SqlDecimal Divide(SqlDecimal x, SqlDecimal y) { return x / y; } ``` 当在 SQL Server 中注册并调用这个函数，且 `y` 参数的值为 0 时，结果如下： ``` Msg 6522, Level 16, State 2, Line 1 A .NET Framework error occurred during execution of user-defined routine or aggregate "Divide": System.DivideByZeroException: Divide by zero error encountered. System.DivideByZeroException: at System.Data.SqlTypes.SqlDecimal.op_Division(SqlDecimal x, SqlDecimal y) at ExpertSQLServer.UserDefinedFunctions.Divide(SqlDecimal x, SqlDecimal y) ``` SQL