sql-server - tsqlt 错误处理胜过存储过程(单元)错误处理程序

Question

当尝试在存储过程中验证用户提供的 GUID 时，使用了一种简单的方法；将用户输入作为 CHAR(36)，然后在 TRY CATCH 中将其显式转换为 UNIQUEIDENTIFIER。然后，CATCH 使用 RAISERROR 将错误与自定义错误描述一起冒泡。

手动运行存储过程，一切都会按预期执行，并且会引发错误。

创建一个 tSQLt 测试来调用该单元(具有 GUID 验证的过程)并处理输出的错误，并与预期错误进行比较，持续失败并出现事务错误； tSQLt 已检测到错误并在 tSQLt 框架内进行处理。

这对我来说表明，tSQLt 正在处理 CAST 到不同数据类型失败的严重性，并且它阻止存储过程中的 TRY/CATCH 来处理它。就像嵌套过程有时会忽略子过程中的 TRY/CATCH 并冒泡到父过程一样；例如，如果子进程。引用了一个不存在的表。

有人遇到过类似的问题吗？只是为了验证我目前的思路。

我已经删除了该测试，并且正在其他地方对其进行测试，但这给我的数据库单元测试带来了“漏洞”。

最后，我想我应该提到，我知道我可以对提供的 CHAR 参数(而不是 CAST)执行不同的验证，并以这种方式引发错误，但这是 tSQLt 查询而不是 tSQL 查询。

编辑

代码示例:

@sGUID 是 CHAR(36)，并且是传递给过程的参数。

BEGIN TRY
    SELECT CAST(@sGUID AS UNIQUEIDENTIFIER)
END TRY 
BEGIN CATCH
    RAISERROR('Invalid GUID format',16,1)
END CATCH

SELECT 行永远不会触发 CATCH tSQLt 似乎会提前进行干预并引发 ROLLBACK 事务错误。

Answer 1

当您调用 RAISEERROR() 时，您将终止 tSQLt 正在运行的事务 --> 因此会出现您所看到的事务错误。

为了进行单元测试而改进这一点，您可能会考虑的一个选择是用对仅包含 RAISERROR() 的自定义存储过程的调用来替换 RAISEERROR() 语句。这样，您就可以单独对该存储过程进行单元测试。

BEGIN TRY
    SELECT CAST(@sGUID AS UNIQUEIDENTIFIER)
END TRY 
BEGIN CATCH
    EXEC dbo.customprocedure
    --RAISERROR('Invalid GUID format',16,1)
END CATCH