Quando qualcosa va storto nel tuo T-SQL, vuoi risolvere il problema rapidamente con un minimo di scavi e interruzioni per gli utenti. I messaggi di errore generati da SQL Server sono altamente tecnici e difficili da comprendere, il che può rendere difficile isolare i problemi e rallentare i tempi di risoluzione. Fortunatamente, i DBA possono implementare SQL Server RAISERROR come alternativa ai messaggi di errore di SQL Server.
RAISERROR è un'istruzione di gestione degli errori di SQL Server che genera un messaggio di errore e avvia l'elaborazione degli errori. RAISERROR può fare riferimento a un messaggio definito dall'utente archiviato nella vista del catalogo sys.messages oppure può creare un messaggio in modo dinamico. Il messaggio viene restituito come messaggio di errore del server all'applicazione chiamante o a un blocco CATCH associato di un costrutto TRY...CATCH.
Esistono diversi scenari in cui è opportuno utilizzare l'istruzione RAISERROR:
- Risoluzione dei problemi relativi al codice Transact-SQL
- Messaggi di ritorno che contengono testo variabile
- Esame dei valori dei dati
- Quando è necessario che l'esecuzione salti da un blocco TRY al blocco CATCH associato o restituisca informazioni di errore dal blocco CATCH ai chiamanti
È importante notare che quando si sviluppano nuove applicazioni, un'istruzione THROW è ora preferibile a RAISERROR per la gestione degli errori. Ma ne parleremo più avanti.
Perché utilizzare RAISERROR per la gestione degli errori di SQL Server?
Esistono due motivi principali per scegliere RAISERROR rispetto alla gestione degli errori generati da SQL Server:
- I messaggi RAISERROR sono personalizzabili per quanto riguarda il livello di gravità e lo stato
- Possono essere scritti in un linguaggio naturale di facile comprensione
RAISERROR restituisce i messaggi di errore all'applicazione nello stesso formato generato da Motore di database di SQL ServerSQL Server Database Engine. Consente agli sviluppatori di generare i propri messaggi di errore, quindi chiunque legga il messaggio sarà in grado di capire qual è il problema reale invece di tentare di decifrare il messaggio di errore tecnico di SQL Server. Gli sviluppatori possono anche impostare il proprio livello di gravità, ID messaggio e stato per i messaggi di errore.
Utilizzo di RAISERROR con il costrutto TRY...CATCH
TRY...CATCH è un costrutto di gestione degli errori che consente di eseguire codice nella sezione TRY e gestire gli errori nella sezione CATCH. In generale, TRY...CATCH è un modo efficace per identificare molti errori T-SQL, ma ci sono alcune eccezioni.
Questo tutorial fornisce una procedura dettagliata su come utilizzare RAISERROR insieme a TRY...CATCH. L'autore utilizza un esempio che mostra come utilizzare RAISERROR all'interno di un blocco TRY per far saltare l'esecuzione al blocco CATCH associato. All'interno del blocco CATCH, l'autore dimostra come utilizzare RAISERROR per restituire le informazioni sull'errore che hanno richiamato il blocco CATCH. L'output mostra l'ID del messaggio, il livello di gravità e lo stato di errore.
RAISERROR vs. THROW Dichiarazioni di gestione degli errori
RAISERROR è stato introdotto in SQL Server 7.0 ed è stato per molti anni un modo efficace per gestire gli errori T-SQL. Ma se stai sviluppando nuove app, Microsoft ora consiglia di usare le istruzioni THROW invece di RAISERROR.
Con l'aggiornamento delle organizzazioni a SQL Server 2012 e versioni successive, RAISERROR viene gradualmente eliminato. In effetti, RAISERROR non può essere utilizzato nelle stored procedure compilate in modo nativo di SQL Server 2014. THROW è considerato un miglioramento rispetto a RAISERROR perché è più facile da usare.
La documentazione di Microsoft SQL Server analizza le differenze tra le istruzioni di gestione degli errori RAISERROR e THROW come segue:
Dichiarazione RAISERROR
- Se un msg_id viene passato a RAISERROR, l'ID deve essere definito in sys.messages.
- Il parametro msg_str può contenere stili di formattazione printf.
Il parametro di gravità specifica la gravità dell'eccezione.
Dichiarazione LANCIO
- Il parametro error_number non deve essere definito in sys.messages.
- Il parametro message non accetta la formattazione in stile printf.
- Non esiste alcun parametro di gravità. La gravità dell'eccezione è sempre impostata su 16.
Sebbene i giorni di RAISERROR possano essere contati, rimane una valida opzione di gestione degli errori nelle versioni precedenti di SQL Server. Microsoft sta spingendo gli utenti delle versioni più recenti di SQL Server (SQL SERVER 2012 e versioni successive) a utilizzare l'istruzione THROW invece di RAISERROR per implementare la gestione degli errori. Microsoft non ha ancora annunciato il ritiro di RAISERROR, ma sembra probabile che lo farà prima o poi.