errore tsqlt gestione manipolazione errori di stored procedure (unità) memorizzata

Question

Durante il tentativo di convalidare un GUID fornito dall'utente all'interno di una stored procedure è stato utilizzato un approccio semplice; prendi l'input dell'utente come CHAR (36), quindi falla esplicitamente come UNIQUEIDENTIFIER all'interno di un TRY CATCH. Quindi CATCH invia l'errore con una descrizione dell'errore personalizzata utilizzando RAISERROR.

Esecuzione manuale della procedura memorizzata tutto si esegue come previsto e l'errore viene generato.

Creare un test tSQLt per chiamare l'unità (la procedura con convalida GUID) e gestire l'errore che viene emesso e confrontare con l'errore atteso che non riesce continuamente con un errore di transazione; tSQLt ha rilevato un errore e gestito all'interno del framework tSQLt.

Questo mi suggerisce che la gravità di un errore di CAST su un diverso tipo di dati viene gestita da tSQLt e impedisce a TRY/CATCH all'interno della stored procedure di gestirlo. Molto simili alle procedure annidate a volte ignorano il TRY/CATCH all'interno della procedura figlio e risalgono alla procedura genitore; Ad esempio, se il bambino proc. fa riferimento a una tabella che non esiste.

Qualcuno ha avuto un problema simile? Semplicemente per convalidare la mia attuale linea di pensiero.

Ho rimosso il test ed è stato testato altrove, ma questo mi ha causato un "buco" nel test dell'unità DB.

Infine, penso che dovrei menzionare che so che posso eseguire una validazione diversa su un parametro CHAR fornito, diverso da un CAST, e generare un errore in questo modo, ma questa è una query tSQLt e non una query tSQL.

EDIT

Esempio di codice:

@sGUID è CHAR (36) ed è un parametro passato alla procedura.

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

La linea SELEZIONA mai innesca il CATCH tSQLt sembra intervenire prima mano e genera l'errore di transazione ROLLBACK.

Answer 1

Quando si chiama RaiseError(), si sta terminando la transazione che tSQLt è in funzione -> quindi l'errore di transazione che stai vedendo.

Per migliorare questo scopo ai fini del test dell'unità, un'opzione che si potrebbe considerare sarebbe quella di sostituire l'istruzione RAISEERROR() con una chiamata a una stored procedure personalizzata che solo contiene RAISERROR(). In questo modo, puoi testare unitariamente quella stored procedure separatamente.

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