Nous savons tous que nous pouvons utiliser l'habillage d'exception (et l'attraper plus tard si nécessaire). Cependant, ce que je voudrais mettre en œuvre (et avec élégance) est de distinguer les types d'erreurs après que le proc stocké est appelé.Erreur Gestion de la flexibilité
J'ai un champ p_error
où le processus stocké vide ses erreurs. Il peut s'agir d'une erreur de validation (où la validation par rapport à la base de données ne peut pas être évitée) ou d'une erreur d'autorisation (nous le faisons à 2 endroits, dont DB) ou d'une erreur SQL.
En bref, j'ai besoin d'un mécanisme joli et élégant pour faire la distinction entre le type d'erreur avant de lancer une exception.
Deux approches que je pensais de:
Au niveau de la base de données ont 3 champs d'erreur: 1 d'autorisation, 1 pour erreur SQL et 1 pour toute autre erreur. Cela pourrait devenir poilu.
Création d'une erreur struct (enum?) Où les messages d'erreur sont stockés et peuvent ensuite être comparés. Encore une fois, trop verbeux. que faire si un message d'erreur dans db change ... à difficile à maintenir.
Autres idées?
Merci. Je vais être plus clair. Il existe 2 types d'erreurs: piégées au niveau de l'application et piégées dans la base de données. Nous n'utilisons pas OracleException; En fait, je suis obligé d'utiliser une classe wrapper qui traite avec Oracle, elle jette ses propres exceptions, que j'attrape. – sarsnake
Mais votre idée est d'utiliser essentiellement des codes d'erreur pour distinguer les types d'erreur. Question: sont ces codes personnalisés? – sarsnake
Les erreurs de saisie à l'intérieur de la base de données I (et beaucoup d'autres) sont très mauvaises. Je suppose que vous revenez à l'intérieur du SP? Cela devrait être la responsabilité de l'application appelante. Quand je dois faire cela, je relance toujours l'exception. Vous pouvez toujours faire mon approche si vous pouvez récupérer le code d'erreur –