Eh bien, je suis un singe du code client qui traite beaucoup de bases de données. Voici comment je gère ça.
Les exceptions (raiseerrors) qui se produisent dans SQL sont propagées à l'appelant. Cela inclurait les contraintes de référence, les violations d'index uniques, les problèmes plus graves, etc.
L'appelant C# devrait avoir ceci :
catch (SQLException sqlEx)
Et puis gérez l'exception si nécessaire. Ils doivent avoir un gestionnaire SQLException spécifique. C'est important.
Je reste généralement à l'écart des paramètres de sortie car je considère que ceux-ci sont liés aux données transportées et non aux messages d'erreur. De plus, je peux inspecter l'exception pour le code d'erreur SQL Server afin que toutes les données dont nous avons besoin soient dans cette exception. /P>
De plus, dans certains cas avec SQL Server, nous avons des procédures stockées qui pourraient déclencher des "exceptions de type métier". Dans ces cas, nous ajoutons un numéro d'erreur personnalisé (supérieur à 50 000) et augmentons cette erreur dans la procédure stockée si nécessaire. En général, nous essayons de les garder au minimum car cela ajoute de la complexité, mais dans certains cas, nous les avons trouvés nécessaires.
Désormais, puisque le client intercepte l'exception SQLException, il peut consulter le code d'erreur renvoyé par SQL Server dans l'exception, puis effectuer une action spéciale (si nécessaire) lorsque l'exception est interceptée et que le numéro d'erreur est une certaine valeur. Cela permet un niveau secondaire de gestion des erreurs basé sur le code d'erreur si cela est requis pour les erreurs personnalisées (> 50000).
Cela permet également aux administrateurs de base de données de générer des erreurs personnalisées et de faire en sorte que le code client ait une manière cohérente de les traiter. Les administrateurs de base de données devraient alors indiquer au singe du code client quelles étaient les erreurs personnalisées afin qu'ils puissent s'y préparer.
Je n'utilise généralement pas les codes de retour à des fins de gestion des erreurs, bien que je puisse voir comment ils pourraient être utilisés, mais cela signifie plus de logique dans la couche code monkey pour examiner et traiter le code de retour. S'il s'agit d'un problème, je veux une exception en retour, car je pourrai alors les traiter de manière cohérente. Si je dois également examiner les codes de retour, il existe maintenant plusieurs possibilités de traitement des erreurs.
