J'essaie de déterminer quelle est la forme correcte des exceptions à jeter serait pour une bibliothèque que j'écris. Un exemple de ce que je dois gérer est d'enregistrer un utilisateur dans une station. Ils le font en balayant un badge. Les choses possibles pouvant aller mal incluent:
Une application utilisant cette bibliothèque devra gérer ces exceptions d'une manière ou d'une autre. Il est possible qu'ils décident de simplement dire "erreur" ou qu'ils voudront peut-être donner aux informations plus utiles à l'utilisateur. Quelle est la meilleure pratique dans cette situation? Créer une exception personnalisée pour chaque possibilité? Utiliser des exceptions existantes? Utilisez une exception et une transaction dans la raison ( nouvelle exception ("badge est désactivée."); )? Je pense que c'est une sorte de mélange des deux premiers, en utilisant des exceptions existantes, le cas échéant, et en créant de nouveaux si nécessaire (et regroupant des exceptions où il est logique).
5 Réponses :
Utilisez une exception et une transmission dans la raison (jeter une nouvelle exception («badge est désactivée».););)
Ceci est certainement une mauvaise pratique, car il viole le but des exceptions - pas seulement pour signaler une situation anormale, mais fournir une capacité à distinguer les exceptions sur un niveau de type, l'utilisateur d'un module peut donc prendre une décision en fonction de un type d'exception.
En règle générale, il est bon de réutiliser des exceptions standard dans la mesure où elles peuvent décrire complètement les situations anormales de votre code. Il est tout à fait difficile de donner un conseil dans une situation actuelle, car des exceptions peuvent souvent dépendre de la sémantique (exception d'argument ou d'une exception d'exploitation non valide (peut-être appropriée pour «leur badge étant désactivée», par exemple).
Je suis essentiellement d'accord avec votre pensée actuelle.
InvalidOperationException doit indiquer une mauvaise opération w / ce qui concerne votre API, pas une violation d'une règle d'affaires.
- Pour des exceptions spécifiques à votre bibliothèque, créez une classe d'exception de base,
BadgeAuthException , et toujours jeter ça. Les scénarios spécifiques devraient chacun avoir leur propre sous-classe ( BadgeDeactivatedException , NoPermissionsAtWorkstationException , etc.) Cette applications façon peut gérer les sous-cas individuels séparément si elles veulent, mais ils peuvent Aussi juste attraper le générique badgeauthexception s'ils ne veulent pas groveler dans des spécificités.
- Quoi que vous fassiez, assurez-vous que le
Message contient toujours des informations utiles au-delà du nom d'exception.
Je pense que vous devez avoir une exception de base et une exception sous-type pour chacune des situitions que vous décrivez (vous pouvez en réalité rendre une erreur DB DB et DB interne pour avoir la même exception de base). Le point clé est qu'il est une bonne pratique d'avoir vos propres exceptions pour votre bibliothèque.
Vous avez deux espèces d'exceptions.
Ceux qui sont spécifiques à votre application, où il est bon d'éviter les exceptions existantes.
Vos exceptions spécifiques à la demande doivent simplifier les cas d'utilisation des personnes qui utilisent vos bibliothèques. 3 de vos exceptions spécifiques à votre application sont des choses que les utilisateurs peuvent faire. Le quatrième (badge n'existe pas) n'est clairement pas procédural, mais beaucoup plus grave.
On dirait que vous avez deux erreurs spécifiques à une application: des objets orientés par l'utilisateur et des erreurs administratives.
Les autres font partie d'un autre morceau de technologie; I.E., erreurs de base de données. Vous pouvez - généralement - ignorer ces. Si la DB n'est pas disponible, l'API lancera des erreurs et vous pouvez laisser ces bulles à travers votre bibliothèque.
Vous pouvez également "envelopper" ceux-ci comme une exception spécifique à une application qui contient une exception de niveau inférieur. Ceci est parfois utile s'il y a beaucoup de technologies de niveau inférieur. Dans votre cas, c'est juste une base de données. Ignorez-le et laissez les erreurs DB à travers.
Vous ne pouvez presque jamais vous tromper en disposant de classes d'exception fines qui prolongent une classe de base commune. De cette façon, les appelants qui ont besoin d'attraper spécifiquement certains et de laisser les autres à travers la boîte et des appelants qui veulent les traiter tous ensemble peuvent le faire.