När något går fel i din T-SQL vill du åtgärda problemet snabbt med minimalt grävande och störningar för användarna. SQL Server-genererade felmeddelanden är mycket tekniska och svåra att förstå, vilket kan göra det svårt att isolera problem och kan sakta ner upplösningstiden. Lyckligtvis kan DBA:er implementera SQL Server RAISERROR som ett alternativ till SQL Server-felmeddelanden.
RAISERROR är en SQL Server-felhanteringssats som genererar ett felmeddelande och initierar felbearbetning. RAISERROR kan antingen referera till ett användardefinierat meddelande som lagras i katalogvyn sys.messages eller så kan det skapa ett meddelande dynamiskt. Meddelandet returneras som ett serverfelmeddelande till den anropande applikationen eller till ett associerat CATCH-block i en TRY...CATCH-konstruktion.
Det finns flera scenarier där det är lämpligt att använda RAISERROR-satsen:
- Felsökning av Transact-SQL-kod
- Returnerande meddelanden som innehåller variabel text
- Undersöka datavärden
- När du behöver körningen för att hoppa från ett TRY-block till det associerade CATCH-blocket eller returnera felinformation från CATCH-blocket till anroparna
Det är viktigt att notera att när man utvecklar nya applikationer är en THROW-sats nu att föredra framför RAISERROR för felhantering. Men mer om det senare.
Varför använda RAISERROR för SQL Server-felhantering?
Det finns två primära skäl till att välja RAISERROR framför SQL Server-genererad felhantering:
- RAISERROR-meddelandena är anpassningsbara med hänsyn till svårighetsgrad och tillstånd
- De kan skrivas på ett naturligt språk som är lätt att förstå
RAISERROR returnerar felmeddelanden till applikationen i samma format som genereras av SQL Server Database Engine. Det tillåter utvecklare att generera sina egna felmeddelanden, så att alla som läser meddelandet kommer att kunna förstå vad det faktiska problemet är istället för att försöka dechiffrera SQL Servers tekniska felmeddelande. Utvecklare kan också ställa in sin egen allvarlighetsgrad, meddelande-ID och status för felmeddelanden.
Använder RAISERROR med TRY...CATCH-konstruktionen
TRY...CATCH är en felhanteringskonstruktion som låter dig exekvera kod i TRY-sektionen och hantera fel i CATCH-sektionen. I allmänhet är TRY...CATCH ett effektivt sätt att identifiera många T-SQL-fel, men det finns några få undantag.
Den här handledningen ger en detaljerad genomgång av hur man använder RAISERROR i kombination med TRY...CATCH. Författaren använder ett exempel som visar hur man använder RAISERROR inuti ett TRY-block för att få exekveringen att hoppa till det associerade CATCH-blocket. Inuti CATCH-blocket visar författaren hur man använder RAISERROR för att returnera felinformationen som anropade CATCH-blocket. Utdatat visar meddelande-ID, allvarlighetsgrad och feltillstånd.
RAISERROR vs. THROW Felhanteringsmeddelanden
RAISERROR introducerades i SQL Server 7.0 och har varit ett effektivt sätt att hantera T-SQL-fel i många år. Men om du utvecklar nya appar rekommenderar Microsoft nu att du använder THROW-satser istället för RAISERROR.
När organisationer uppdaterar till SQL Server 2012 och senare fasas RAISERROR ut. Faktum är att RAISERROR inte kan användas i SQL Server 2014:s inbyggda kompilerade lagrade procedurer. THROW anses vara en förbättring jämfört med RAISERROR eftersom det är lättare att använda.
Microsofts SQL Server-dokumentation bryter ner skillnaderna mellan RAISERROR- och THROW-felhanteringssatserna enligt följande:
RAISERROR-sats
- Om ett msg_id skickas till RAISERROR måste ID:t definieras i sys.messages.
- parametern msg_str kan innehålla formateringsstilar för printf.
Severity-parametern anger svårighetsgraden av undantaget.
THROW-uttalande
- parametern error_number behöver inte definieras i sys.messages.
- Meddelandeparametern accepterar inte formatering av printf-format.
- Det finns ingen allvarlighetsparameter. Undantagets svårighetsgrad är alltid inställd på 16.
Även om RAISERRORs dagar kan vara räknade, är det fortfarande ett fungerande felhanteringsalternativ på äldre versioner av SQL Server. Microsoft pressar användare av nyare versioner av SQL Server (SQL SERVER 2012 och högre) att använda THROW-satsen istället för RAISERROR för att implementera felhantering. Microsoft har inte meddelat RAISERROR-fasning ännu, men det verkar troligt att det kommer att göra det förr snarare än senare.