Nou, ik ben een klantcode-aap die veel met databases omgaat. Hier is hoe ik het aanpak.
Uitzonderingen (raiseerrors) die in SQL voorkomen, worden teruggestuurd naar de beller. Dit omvat ref-beperkingen, unieke indexschendingen, serieuzere problemen, enz. In principe zou alles dat de gegevensbewerking niet normaal zou laten plaatsvinden, terug moeten worden gepropageerd.
De beller C# zou dit moeten hebben:
catch (SQLException sqlEx)
En behandel de uitzondering vervolgens indien nodig. Ze moeten een specifieke SQLException-handler hebben. Dit is belangrijk.
Ik blijf over het algemeen weg van uitvoerparameters omdat ik van mening ben dat deze gerelateerd zijn aan de gegevens die worden getransporteerd en niet aan foutmeldingen. Bovendien kan ik de uitzondering voor de SQL Server-foutcode inspecteren, zodat alle gegevens die we nodig hebben in die uitzondering moeten staan.
Bovendien hebben we in sommige gevallen met SQL Server opgeslagen procedures die "zakelijke uitzonderingen" kunnen veroorzaken. In die gevallen voegen we een aangepast foutnummer toe (boven de 50000) en verhogen we die fout in de opgeslagen procedure wanneer dat nodig is. Over het algemeen proberen we deze tot een minimum te beperken, omdat het complexiteit toevoegt, maar in sommige gevallen hebben we geconstateerd dat ze nodig zijn.
Omdat de client nu de SQLException opvangt, kunnen ze de foutcode bekijken die door SQL Server in de uitzondering wordt geretourneerd en vervolgens een speciale actie ondernemen (indien nodig) wanneer de uitzondering wordt opgevangen en het foutnummer een bepaalde waarde is. Dit maakt een secundair niveau van foutafhandeling mogelijk op basis van de foutcode als dat nodig is voor de aangepaste fouten (>50000).
Hierdoor kunnen de DBA's ook aangepaste fouten genereren en heeft de klantcode een consistente manier om hiermee om te gaan. De DBA's zouden dan de code-aap van de klant moeten vertellen wat de aangepaste fouten waren, zodat ze zich daarop konden voorbereiden.
Ik gebruik de retourcodes meestal niet voor foutafhandelingsdoeleinden, hoewel ik kan zien hoe ze kunnen worden gebruikt, maar dat betekent meer logica in de code-aaplaag om naar de retourcode te kijken en ermee om te gaan. Als ze een probleem vormen, wil ik een uitzondering terug, want dan kan ik er consequent mee omgaan. Als ik ook naar retourcodes moet kijken, zijn er nu meerdere mogelijkheden voor foutafhandeling.