Når noget går galt i din T-SQL, vil du gerne løse problemet hurtigt med minimal udgravning og forstyrrelse for brugerne. SQL Server-genererede fejlmeddelelser er meget tekniske og svære at forstå, hvilket kan gøre det vanskeligt at isolere problemer og kan sinke løsningstiden. Heldigvis kan DBA'er implementere SQL Server RAISERROR som et alternativ til SQL Server-fejlmeddelelser.
RAISERROR er en SQL Server-fejlhåndteringserklæring, der genererer en fejlmeddelelse og starter fejlbehandling. RAISERROR kan enten referere til en brugerdefineret meddelelse, der er gemt i sys.messages-katalogvisningen, eller den kan bygge en meddelelse dynamisk. Meddelelsen returneres som en serverfejlmeddelelse til den kaldende applikation eller til en tilknyttet CATCH-blok af en TRY...CATCH-konstruktion.
Der er flere scenarier, hvor det er passende at bruge RAISERROR-sætningen:
- Fejlfinding af Transact-SQL-kode
- Returnering af beskeder, der indeholder variabel tekst
- Undersøgelse af dataværdier
- Når du har brug for udførelsen for at hoppe fra en TRY-blok til den tilhørende CATCH-blok eller returnere fejlinformation fra CATCH-blokken til opkalderne
Det er vigtigt at bemærke, at når man udvikler nye applikationer, er en THROW-sætning nu at foretrække frem for RAISERROR til fejlhåndtering. Men mere om det senere.
Hvorfor bruge RAISERROR til SQL Server-fejlhåndtering?
Der er to primære grunde til at vælge RAISERROR frem for SQL Server-genereret fejlhåndtering:
- RAISERROR-meddelelserne kan tilpasses med hensyn til sværhedsgrad og tilstand
- De kan skrives i et naturligt sprog, der er let at forstå
RAISERROR returnerer fejlmeddelelser til applikationen i det samme format, som er genereret af SQL Server Database Engine. Det giver udviklere mulighed for at generere deres egne fejlmeddelelser, så enhver, der læser beskeden, vil være i stand til at forstå, hvad det faktiske problem er i stedet for at forsøge at tyde SQL Servers tekniske fejlmeddelelse. Udviklere kan også indstille deres eget sværhedsgrad, meddelelses-id og tilstand for fejlmeddelelser.
Brug af RAISERROR med TRY...CATCH-konstruktionen
TRY...CATCH er en fejlhåndteringskonstruktion, der lader dig udføre kode i TRY-sektionen og håndtere fejl i CATCH-sektionen. Generelt er TRY...CATCH en effektiv måde at identificere mange T-SQL-fejl på, men der er nogle få undtagelser.
Denne tutorial giver en detaljeret gennemgang af, hvordan du bruger RAISERROR i forbindelse med TRY...CATCH. Forfatteren bruger et eksempel, der viser, hvordan man bruger RAISERROR inde i en TRY-blok for at få eksekveringen til at hoppe til den tilhørende CATCH-blok. Inde i CATCH-blokken demonstrerer forfatteren, hvordan man bruger RAISERROR til at returnere den fejlinformation, der påkaldte CATCH-blokken. Outputtet viser meddelelses-ID, sværhedsgrad og fejltilstand.
RAISERROR vs. THROW-fejlhåndteringserklæringer
RAISERROR blev introduceret i SQL Server 7.0 og har været en effektiv måde at håndtere T-SQL-fejl på i mange år. Men hvis du udvikler nye apps, anbefaler Microsoft nu at bruge THROW-sætninger i stedet for RAISERROR.
Efterhånden som organisationer opdaterer til SQL Server 2012 og nyere, udfases RAISERROR. Faktisk kan RAISERROR ikke bruges i SQL Server 2014s oprindeligt kompilerede Stored Procedures. THROW betragtes som en forbedring i forhold til RAISERROR, fordi det er nemmere at bruge.
Microsofts SQL Server-dokumentation opdeler forskellene mellem RAISERROR- og THROW-fejlhåndteringssætningerne som følger:
RAISERROR-erklæring
- Hvis et msg_id sendes til RAISERROR, skal ID'et defineres i sys.messages.
- Msg_str-parameteren kan indeholde printf-formatering.
Alvorlighedsparameteren angiver undtagelsens alvorlighed.
KAST-erklæring
- Error_number-parameteren behøver ikke at være defineret i sys.messages.
- Meddelelsesparameteren accepterer ikke printf-formatering.
- Der er ingen alvorlighedsparameter. Alvorligheden af undtagelsen er altid sat til 16.
Selvom RAISERRORs dage kan være talte, forbliver det en levedygtig fejlhåndteringsmulighed på ældre versioner af SQL Server. Microsoft presser brugere af nyere versioner af SQL Server (SQL SERVER 2012 og nyere) til at bruge THROW-sætningen i stedet for RAISERROR til at implementere fejlhåndtering. Microsoft har endnu ikke annonceret RAISERROR-afskrivning, men det ser ud til, at det vil ske før end senere.