TRY/CATCH 块与 SQL 检查

Posted 2023-05-08

【中文标题】TRY/CATCH 块与 SQL 检查

【英文标题】：TRY/CATCH block vs SQL checks

【发布时间】：2013-11-21 16:36:16

【问题描述】：

简而言之，我想知道以下哪个是更好的做法：

将我的代码封装在TRY/CATCH 块中并显示错误消息 编写自己的检查并显示自定义错误消息

正如我所读，TRY/CATCH 块并未处理所有类型的错误。在我的情况下，这不是问题。

我正在构建执行特定存储过程的动态 SQL。我可以自己检查：

要执行的过程是否存在 是否提供所有参数 可以正确转换所有值

或者只是像这样封装语句：

BEGIN TRY           
    EXEC sp_executesql @DynamicSQLStatement
    SET @Status = 'OK'
END TRY
BEGIN CATCH
    SET @Status =  ERROR_MESSAGE()
END CATCH

如果我自己进行检查（例如性能差异）或者我应该把这项工作留给服务器，会有什么不同吗？

我问的原因是因为在某些语言（如 javascript）中，使用 try/catch 块被称为不好的做法。

【参考方案1】：

通常情况下，自己检查这些事情比让 SQL Server 捕获异常要好。正如我在这些帖子中所展示的那样，异常处理并不便宜：

Checking for potential constraint violations before entering SQL Server TRY and CATCH logic

Performance impact of different error handling techniques

根据您预期的架构、容量、并发性和失败频率，您的临界点可能会有所不同，因此在非常大的规模下，这可能并不总是绝对最有效的方法。但除了在大多数情况下您会过得更好之外，编写自己的错误处理和预防（虽然这需要时间）可以让您完全了解所有错误情况。

话虽如此，您仍然应该将TRY / CATCH 用作故障保险，因为总会有您无法预料的异常情况，并且让它优雅地爆炸比到处扔弹片要好得多。

【讨论】：

非常感谢，对您文章的引用正是我想要的。

【参考方案2】：

try/catch 只能用于严重错误。如果您可以通过执行简单的 if 语句来防止可能出现的错误，那么您应该这样做。例如，不要依赖 try/catch 来确保用户输入了正确格式的日期。自己检查一下。

就个人而言，如果我遇到这样的严重异常，我更愿意查看调用堆栈以及它发生的位置。所以，我只在项目的最顶层做一个 try/catch。

【参考方案3】：

使用 Try Catch Block 您仍然可以引发自定义错误消息，实际上如果您有自定义错误消息，那么您只能显示自定义错误消息，您不能使用 sql server 默认错误消息。您还可以使用许多其他错误函数来获取有关您的错误的更多信息，例如

ERROR_LINE()
ERROR_MESSAGE()
ERROR_STATE()
ERROR_NUMBER()
ERROR_STATE(),

这些功能只能在 TRY/CATCH 块的 Catch 块中使用，让我们作为开发人员的生活变得更轻松:)