ストアド プロシージャ内でユーザーが指定した GUID を検証しようとすると、単純な方法が使用されました。ユーザー入力を CHAR(36) として受け取り、それを TRY CATCH 内で UNIQUEIDENTIFIER として明示的にキャストします。CATCH は、RAISERROR を使用してカスタム エラーの説明でエラーをバブルします。
ストアド プロシージャを手動で実行すると、すべてが期待どおりに実行され、エラーが発生します。
ユニット (GUID 検証を伴うプロシージャ) を呼び出す tSQLt テストを作成し、出力されたエラーを処理して、予想されるエラーと比較すると、トランザクション エラーで継続的に失敗します。tSQLt がエラーを検出し、tSQLt フレームワーク内で処理しました。
これは、異なるデータ型への CAST の失敗の重大度が tSQLt によって処理されており、ストアド プロシージャ内の TRY/CATCH がそれを処理するのを妨げていることを示唆しています。ネストされたプロシージャと同様に、子プロシージャ内の TRY/CATCH が無視され、親プロシージャにバブルアップすることがあります。例は、子プロシージャの場合です。存在しないテーブルを参照しています。
誰かに同様の問題がありましたか？単に私の現在の考え方を検証するだけです。
テストを削除し、他の場所でテストされていますが、これにより、DB 単体テストに「穴」ができました。
最後に、提供された 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 トランザクション エラーをスローします。