2009-04-07 12 views
1

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:

  1. 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.

  2. 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?

Répondre

1

Je ne vois pas pourquoi les gens continuent à faire ce non-sens p_error. Au moins avec oracle (et je suis tout à fait sûr avec sql server aussi) le résultat de l'appel d'une procédure stockée qui déclenche une exception est une exception déclenchée qui contient beaucoup plus d'informations que ce champ idiot p_error peut éventuellement.

Encore une fois, mon expérience récente est tout simplement avec oracle mais je voudrais écrire un wrapper pour tous les appels de procédure stockée (pratique standard de toute façon) et à l'intérieur quelque chose comme ça

try { 
    RunMyStoredProcedure(); 
} 
catch(OracleException e) { 
    new OracleExceptionProcessor().HandleException(e); 
} 
//... 
//... 
class OracleExceptionProcessor { 
    static List<int> _validationErrorCodes = new List<int> { 123, 456}; 
    static List<int> _authenticationErrorCodes = new List<int> { 789}; 

    public void HandleException(OracleException ex) { 
    if(_validationErrorCodes.Any(c==ex.ErrorCode)) 
     throw new DatabaseValidationError(ex); 
    if(_authenticationErrorCodes.Any(c==ex.ErrorCode)) 
     throw new DatabaseAuthenticationError(ex); 
    throw new DatabaseSQLError(ex); 
    } 
} 

Puisque je ne peux pas imaginer la base de données ayant tous ces nombreux codes d'erreur de validation ou d'authentification cela devrait être assez simple et facile.

+0

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

+0

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

+0

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 –