sql >> Databasteknik >  >> RDS >> Sqlserver

SQL Server-felhantering:undantag och databasklientkontraktet

Jo, jag är en klientkod-apa som sysslar mycket med databaser. Så här hanterar jag det.

Undantag (raiseerrors) som händer i SQL sprids tillbaka till den som ringer. Detta skulle inkludera ref-begränsningar, unika indexöverträdelser, allvarligare problem, etc. I princip allt som inte skulle få dataoperationen att ske normalt bör spridas tillbaka.

Den som ringer C# bör ha detta:

catch (SQLException sqlEx)

Och hantera sedan undantaget efter behov. De bör ha en specifik SQLException-hanterare. Detta är viktigt.

Jag håller mig i allmänhet borta från utdataparametrar eftersom jag anser att de är relaterade till data som transporteras och inte några felmeddelanden, dessutom kan jag inspektera undantaget för SQL Server-felkoden så att all data vi behöver ska finnas i det undantaget.

Dessutom, i vissa fall med SQL Server, har vi lagrade procedurer som kan leda till "affärstyp av undantag". I dessa fall lägger vi till ett anpassat felnummer (över 50000) och höjer det felet i den lagrade proceduren när det behövs. I allmänhet försöker vi hålla dessa på ett minimum eftersom det ökar komplexiteten, men i vissa fall har vi funnit att de är nödvändiga.

Nu, eftersom klienten fångar SQLException, kan de titta på felkoden som returneras av SQL Server i undantaget och sedan vidta någon speciell åtgärd (om det behövs) när undantaget fångas och felnumret är ett visst värde. Detta tillåter en sekundär nivå av felhantering baserat på felkoden om det krävs för de anpassade felen (>50 000).

Detta gör också att DBA:erna kan ta upp anpassade fel och att klientkoden har ett konsekvent sätt att hantera dem. DBA:erna skulle sedan behöva berätta för klientkodapan vad de anpassade felen var så att de kunde förbereda sig för dem.

Jag brukar inte använda returkoderna i felhanteringssyfte, även om jag kan se hur de skulle kunna användas, men det innebär mer logik i kodaplagret att titta på och hantera returkoden. Om de är ett problem vill jag ha tillbaka ett undantag, för då kan jag hantera dem konsekvent. Om jag måste titta på returkoder också, nu finns det flera vägar för felhantering.



  1. Hantera en PostgreSQL Commitfest

  2. Hur vet man om en sql-sats körs i java?

  3. lång omröstningsinformation från mysql fungerar inte

  4. Förstå Oracle-aliasing - varför känns inte ett alias igen i en fråga om det inte är insvept i en andra fråga?