Implementer struktureret undtagelseshåndtering
Nu, hvor du har en forståelse af arten af fejl og grundlæggende fejlhåndtering i T-SQL, er det tid til at se på en mere avanceret form for fejlhåndtering. Struktureret undtagelseshåndtering blev introduceret i SQL Server 2005.
Her kan du se, hvordan du bruger den og evaluerer dens fordele og begrænsninger, herunder TRY CATCH-blokken, rollen som funktioner til fejlhåndtering og forståelse af forskellen mellem opfangelige og ikke-sammenkædede fejl. Endelig kan du se, hvordan fejl kan administreres og vises, når det er nødvendigt.
Hvad er TRY/CATCH-blokprogrammering
Struktureret undtagelseshåndtering er mere effektiv end fejlhåndtering baseret på @@ERROR systemvariabel. Det giver dig mulighed for at forhindre kode i at blive fyldt med fejlhåndteringskode og centralisere denne kode til håndtering af fejl. Centralisering af fejlhåndteringskoden betyder også, at du kan fokusere mere på formålet med koden i stedet for den fejlhåndtering, den indeholder.
TRY-blok og CATCH-blok
Når du bruger struktureret undtagelseshåndtering, placeres kode, der kan udløse en fejl, i en TRY-blok. TRY-blokke er omsluttet af BEGIN TRY- og END TRY-sætninger.
Hvis der opstår en fejl, der kan fanges – de fleste fejl kan registreres, flyttes udførelseskontrolelementet til CATCH-blokken. CATCH-blokken er en række T-SQL-sætninger omsluttet af BEGIN CATCH - og END CATCH-sætninger .
Seddel
Mens BEGIN CATCH og END TRY er separate sætninger, skal BEGIN CATCH straks følge slut-TRY.
Aktuelle begrænsninger
Sprog på højt niveau tilbyder ofte en try/catch/endelig-konstruktion og bruges ofte til implicit at frigive ressourcer. Der er ingen tilsvarende ENDELIG-blok i T-SQL.
Forstå forskellen mellem catchable og noncatchable fejl
Det er vigtigt at indse, at selvom TRY/CATCH-blokke giver dig mulighed for at fange et meget større udvalg af fejl, end du kunne med @@ERROR, kan du ikke fange alle typer.
Opfangelige fejl i forhold til fejl, der ikke kan registreres
Det er ikke alle fejl, der kan registreres af TRY/CATCH-blokke inden for det samme område, hvor TRY/CATCH-blokken findes. Ofte kan fejl, der ikke kan fanges i det samme område, fanges i et omgivende område. Du kan f.eks. ikke registrere en fejl i den lagrede procedure, der indeholder TRY/CATCH-blokken. Du vil dog sandsynligvis registrere denne fejl i en TRY/CATCH-blok i den kode, der kaldte den lagrede procedure, hvor fejlen opstod.
Almindelige fejl, der ikke kan sammenkædes
Almindelige eksempler på fejl, der ikke kan slettes, er:
- Kompiler fejl, f.eks. syntaksfejl, der forhindrer en batch i at kompilere.
- Problemer med genkompilering på sætningsniveau, der normalt er relateret til udskudt navneløsning. Du kan f.eks. oprette en lagret procedure, der refererer til en ukendt tabel. Der udløses kun en fejl, når proceduren forsøger at oversætte navnet på tabellen til et objectid.
Sådan gentrækkes fejl ved hjælp af THROW
Hvis THROW-sætningen bruges i en CATCH-blok uden parametre, vil den gentrække den fejl, der fik koden til at indtaste CATCH-blokken. Du kan bruge denne teknik til at implementere fejllogføring i databasen ved at registrere fejl og logge deres oplysninger og derefter sende den oprindelige fejl til klientprogrammet, så det kan håndteres der.
Her er et eksempel på, hvordan du omstyrte en fejl.
BEGIN TRY
-- code to be executed
END TRY
BEGIN CATCH
PRINT ERROR_MESSAGE();
THROW
END CATCH
I nogle tidligere versioner af SQL Server var der ingen metode til at udløse en systemfejl. Selvom THROW ikke kan angive en systemfejl, der skal udløses, når THROW bruges uden parametre i en CATCH-blok, vil den reraise både system- og brugerfejl.
Hvad er funktioner til fejlhåndtering
CATCH-blokke gør de fejlrelaterede oplysninger tilgængelige i hele CATCH-blokkens varighed. Dette omfatter underskoper, f.eks. lagrede procedurer, der køres fra CATCH-blokken.
Funktioner til fejlhåndtering
Du skal huske, at den værdi, som @@ERROR systemvariabel indeholdt, blev nulstillet, da programmeringen med @@ERROR blev nulstillet, så snart den næste sætning blev udført.
En anden vigtig fordel ved struktureret undtagelseshåndtering i T-SQL er, at der er angivet en række fejlhåndteringsfunktioner, og disse bevarer deres værdier i hele CATCH-blokken. Separate funktioner angiver hver egenskab for en fejl, der er opstået.
Det betyder, at du kan skrive generiske fejlhåndteringslagrede procedurer, der stadig kan få adgang til de fejlrelaterede oplysninger.
- CATCH-blokke gør de fejlrelaterede oplysninger tilgængelige i hele CATCH-blokkens varighed.
- @@Error nulstilles, når den næste sætning køres.
Administrer fejl i kode
SQL CLR-integration gør det muligt at udføre administreret kode i SQL Server. .NET-sprog på højt niveau, f.eks. C# og VB, har detaljeret undtagelseshåndtering tilgængelig for dem. Fejl kan registreres ved hjælp af almindelige .NET-forsøg/catch/til sidst-blokke.
Fejl i administreret kode
Generelt ønsker du måske at registrere fejl i administreret kode så meget som muligt. Det er dog vigtigt at indse, at eventuelle fejl, der ikke håndteres i den administrerede kode, overføres tilbage til den kaldende T-SQL-kode. Når fejl, der opstår i administreret kode, returneres til SQL Server, ser det ud til at være en 6522-fejl. Fejl kan indlejres, og denne bestemte fejl vil ombryde den egentlige årsag til fejlen.
En anden sjælden, men mulig årsag til fejl i administreret kode er, at koden kan udføre en RAISERROR T-SQL-sætning via et SqlCommand-objekt.