Approches pour la gestion des codes d'erreur et des messages dans .NET

Question

Recherche de suggestions/bonnes pratiques pour la gestion des codes d'erreur et des messages dans une application multi-niveaux. Plus précisément des choses comme:

1. Où les codes d'erreur devraient-ils être définis? Enum? Classe?
2. Comment les messages d'erreur ou autres détails sont-ils associés aux codes d'erreur? fichiers de ressources attributs sur les valeurs enum, etc.?
3. Si vous avez une application multiniveau composée de projets DAL, BLL, UI et Common par exemple, devrait-il y avoir une seule liste de codes pour tous les niveaux, ou les codes sont-ils extensibles par projet/niveau?

Mise à jour: Il est important de mentionner que je ne peux pas compter uniquement sur les exceptions et les types d'exception personnalisés pour les rapports d'erreurs, car certains clients pour cette application seront via des services Web (SOAP & REST) ​​

Toutes suggestions sont les bienvenues!

Answer 1

Je pense qu'il est préférable de créer un projet commun (ou ApplicationFramework projet) et de mettre vos exceptions et Common Object sur elle.

Il est toujours une bonne idée d'avoir une ApplicationFramework qui contient la classe de base pour vos classes (spécialement dans l'interface utilisateur - PageBase - MasterBase- ModuleBase et etc)

Et comme évident que vous devez mettre vos classes et Enums dans votre projet BLL.

Notez que 3 niveaux ne signifie pas 3 Projet. Vous pouvez avoir 5 projets dans votre BLL.

Enfin, n'oubliez pas d'utiliser ELMAH ou d'autres outils similaires.

Answer 2

Les codes d'erreur sont anciens, vous en aviez besoin dans le mauvais vieux temps de programmation COM et C, les environnements qui ne supportaient pas les exceptions. De nos jours, vous utilisez des exceptions pour notifier le code client ou l'utilisateur à propos de problèmes. Les exceptions dans .NET sont auto-descriptives, elles ont un type, un message et des diagnostics.

Vous devez distinguer deux types d'exceptions, celles qui sont raisonnablement récupérables et celles où vous n'avez aucune idée de ce qui s'est vraiment mal passé ou de la façon dont vous en récupérez. Ce dernier type est de loin le plus commun, vous aurez besoin d'un humain pour prendre des mesures correctives. Utilisez l'un des types d'exception .NET intégrés standard pour les élever. IllegalOperationException, FormatException, ArgumentException sont des choix courants. Si c'est le back-end qui soulève une telle exception, alors vous voulez juste le passer sans altérer. Vous avez généralement besoin d'un bloc finally pour vous assurer que votre état interne est cohérent, parfois un bloc catch qui contient un simple throw pour récupérer l'état. Tout ce que vous considérez récupérable doit être déclenché avec un type d'exception que vous déclarez vous-même, dérivé de la classe Exception. Cela donne au code en amont une chance d'écrire une clause catch et de faire quelque chose de significatif. Vous devez générer un message descriptif du problème, au cas où le code en amont ne le gère pas, le texte du message doit être extrait d'une chaîne codée en dur ou d'une ressource si vous soutenir la localisation.