Nå, jeg er en klientkodeabe, der beskæftiger sig meget med databaser. Sådan håndterer jeg det.
Undtagelser (raiseerrors), der sker i SQL, spredes tilbage til den, der ringer. Dette vil omfatte ref-begrænsninger, unikke indeksovertrædelser, mere alvorlige problemer osv. Dybest set alt, der ikke ville få dataoperationen til at ske normalt, bør spredes tilbage.
Den, der ringer C#, skal have dette:
catch (SQLException sqlEx)
Og håndter så undtagelsen efter behov. De skal have en specifik SQLException-handler. Dette er vigtigt.
Jeg holder mig generelt væk fra outputparametre, fordi jeg anser dem for at være relateret til de data, der transporteres, og ikke nogen fejlmeddelelser, desuden kan jeg inspicere undtagelsen for SQL Server-fejlkoden, så alle de data, vi har brug for, skal være i denne undtagelse.
Derudover har vi, i nogle tilfælde med SQL Server, Stored Procedures, der kan give anledning til "forretningstype undtagelser". I disse tilfælde tilføjer vi et brugerdefineret fejlnummer (over 50000) og rejser denne fejl i den lagrede procedure, når det er nødvendigt. Generelt forsøger vi at holde disse på et minimum, fordi det tilføjer kompleksitet, men i nogle tilfælde har vi fundet dem nødvendige.
Nu, da klienten fanger SQLExceptionen, kan de se på fejlkoden returneret af SQL Server i undtagelsen og derefter foretage enhver speciel handling (hvis det er nødvendigt), når undtagelsen er fanget og fejlnummeret er en bestemt værdi. Dette tillader et sekundært niveau af fejlhåndtering baseret på fejlkoden, hvis det er påkrævet for de tilpassede fejl (>50000).
Dette giver også DBA'erne mulighed for at rejse brugerdefinerede fejl og få klientkoden til at have en ensartet måde at håndtere dem på. DBA'erne skulle derefter fortælle klientkodeaben, hvad de tilpassede fejl var, så de kunne forberede sig på dem.
Jeg bruger normalt ikke returkoderne til fejlhåndteringsformål, selvom jeg kan se hvordan de kunne bruges, men det betyder mere logik i kodeabelaget til at se på og håndtere returkoden. Hvis de er et problem, vil jeg gerne have en undtagelse tilbage, for så kan jeg håndtere dem konsekvent. Hvis jeg også skal se på returkoder, er der nu flere muligheder for fejlhåndtering.