我们目前正在使用SQL 2005，我正在将旧的Foxpro系统迁移到由SQL Server支持的新Web应用程序。我在T-SQL中使用TRY CATCH进行事务处理，它似乎运行良好。工作中的其他程序员之一对此感到担忧，因为他说他听说过流行语并不总是能捕捉到错误的问题。我已经把 sproc 打死了，无法让它失败（错过一个接球），我在网上搜索时发现的唯一问题是它不会返回错误号<5000 的正确错误号。有没有人遇到过 T-SQL 中的 TRY CATCH 的任何其他问题 - 特别是如果它错过了一个捕获？感谢您提供的任何意见。
TRY ... CATCH 不会捕获每个可能的错误，但未捕获的错误在不受 TRY 影响的 BOL 错误中得到了很好的记录...捕获构造
尝试。。。CATCH 构造不会捕获 以下条件：
- 严重性为 10 或更低的警告或信息性消息。
- 严重性为 20 或更高的错误停止 SQL Server 数据库引擎任务处理 会话。如果发生错误 严重性为 20 或更高，并且 数据库连接未中断， 尝试。。。CATCH 将处理该错误。
- 注意事项，例如客户端中断请求或中断 客户端连接。
- 当系统管理员使用 KILL 结束会话时 陈述。
以下类型的错误不是 由 CATCH 块处理时 在同一执行级别发生 作为尝试...捕获结构：
编译错误，
- 例如语法错误，阻止批处理 运行。
- 语句级重新编译期间发生的错误，例如 对象名称解析错误 编译后发生，因为 延迟名称解析。
这些错误将返回到关卡 运行批处理、存储过程、 或触发器。
在我的经验中，有一个案例是 TRY...CATCH 块未捕获错误。与排序规则相关的错误：无法解决等于操作中"Latin1_General_CI_AS"和"Latin1_General_CI_AI"之间的排序规则冲突。也许此错误对应于 BOL 中记录的错误类型之一。
语句级重新编译期间发生的错误，例如对象 编译后由于以下原因而发生的名称解析错误 延迟名称解析。
"错误"搜索词传递给CONTAINSTABLE，TRY ... CATCH将无法捕获错误
例如：
DECLARE @WordList VARCHAR(800)
SET @WordList = 'crap"s'
CON
TAINSTABLE(table, *, @WordList)
CONTAINSTABLE会给你一个"语法错误"，任何周围的TRY ... CATCH都不会捕捉到这一点。
这尤其令人讨厌，因为错误是由数据引起的，而不是由代码中的"真实"语法错误引起的。
我在SQL Server 2008工作。我构建了一个大的sql语句，它有一个尝试/捕获。我通过重命名表（在 dev 中）对其进行了测试。该语句炸毁了，没有捕获错误。SQL Server中的try/catch很弱，但总比没有好。这是我的一段代码。由于我公司的限制，我不能再投入了。
COMMIT TRAN T1;
END TRY
BEGIN CATCH
-- Save the error.
SET @ErrorNumber = ERROR_NUMBER();
SET @ErrorMessage = ERROR_MESSAGE();
SET @ErrorLine = ERROR_LINE();
-- Put GSR.dbo.BlahBlahTable back the way it was.
ROLLBACK TRAN T1;
END CATCH
-- Output a possible error message. Knowing what line the error happened at really helps with debugging.
SELECT @ErrorNumber as ErrorNumber,@ErrorMessage as ErrorMessage,@ErrorLine AS LineNumber;
我从未遇到过尝试的情况...抓住。。。失败。Neiteher可能有很多人读过这个问题。唉，这只意味着如果有这样的SQL错误，那么我们还没有看到它。问题是，这是一个相当大的"如果"。信不信由你，Microsoft确实付出了一些努力使他们的核心软件产品非常可靠，并且尝试...抓住。。。几乎不是一个新概念。举个简单的例子：在 SQL 2005 中，我在制定当时新的表分区时遇到了一个可靠的、可演示的和可复制的错误——这个错误已经被补丁修复了。并尝试...抓住。。。比表分区更频繁地使用。
我想说举证责任落在你的同事身上。如果他"在某处听到"，那么他应该尝试用某种证据来支持它。互联网上充满了老话的证据"仅仅因为每个人都这么说，并不意味着他们是对的"。