Meilleures pratiques pour créer un modèle de codes d'erreur pour un projet d'entreprise en C #
Je travaille sur un projet d'entreprise qui sera déployé dans de nombreuses PME et entreprises.
Le support de ce projet aurait du mal et je veux donc créer un modèle de codage pour les erreurs ( Comme les codes de statut HTTP ). Cela permettra aux personnes du service d'assistance de se référer aux documents et de résoudre les problèmes dès que possible.
Quelles sont les meilleures pratiques et recommandations pour ce faire?
Toute aide pour ce faire sera utile.
Il existe une différence entre les codes d'erreur et les valeurs de retour d'erreur. Un code d'erreur est destiné à l'utilisateur et au service d'assistance. Une valeur de retour d'erreur est une technique de codage pour indiquer que votre code a rencontré une erreur.
On peut implémenter des codes d'erreur en utilisant des valeurs de retour d'erreur, mais je déconseille cela. Les exceptions sont le moyen moderne de signaler les erreurs, et il n'y a aucune raison pour qu'elles ne portent pas de code d'erreur.
Voici comment je l'organiserais (notez que les points 2-6 sont indépendants de la langue):
- Utilisez un type d'exception personnalisé avec une propriété
ErrorCodesupplémentaire. La capture dans la boucle principale signalera ce champ de la manière habituelle (fichier journal/fenêtre contextuelle d'erreur/réponse d'erreur). Utilisez le même type d'exception dans tout votre code. - Ne commencez pas à 1 et n'utilisez pas de zéros non significatifs. Gardez tous les codes d'erreur à la même longueur, donc un mauvais code d'erreur est facile à repérer. Commencer à 1000 est généralement suffisant. Ajoutez peut-être un "E" de tête pour les rendre clairement identifiables pour les utilisateurs (particulièrement utile lorsque le support technique doit indiquer aux utilisateurs comment repérer le code d'erreur).
- Gardez une liste de tous les codes d'erreur, mais ne faites pas cela dans votre code . Gardez une courte liste sur une page wiki pour les développeurs, qu'ils peuvent facilement modifier lorsqu'ils ont besoin d'un nouveau code. Le service d'assistance devrait avoir une liste distincte sur son propre wiki.
- N'essayez pas d'appliquer une structure sur les codes d'erreur. Il y aura toujours des erreurs difficiles à classer et vous ne voulez pas discuter pendant des heures si une erreur doit être dans le groupe 45xx ou dans le groupe 54xx. Soyez pragmatique.
- Attribuez à chaque lancer de votre code un code distinct. Même si vous pensez que c'est la même cause, le service d'assistance peut avoir besoin de faire différentes choses dans différents cas. Il est plus facile pour eux d'avoir "E1234: Voir E1235" dans leur wiki, que d'amener l'utilisateur à avouer ce qu'il a fait de mal.
- Divisez les codes d'erreur si le service d'assistance le demande. Une simple ligne
if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");dans votre code peut économiser une demi-heure pour le service d'assistance.
Et n'oubliez jamais que le but des codes d'erreur est de faciliter la vie du service d'assistance.
Vous devez d'abord isoler les zones où des erreurs peuvent se produire et être visibles par l'utilisateur. Ensuite, vous pouvez les documenter. C'est si simple.
Eh bien, simple en théorie .. dans la pratique, des erreurs peuvent se produire partout, et les signaler peut transformer le code Nice en un monstre de journalisation, de levée et de gestion des exceptions et de transmission de valeurs de retour.
Je recommanderais alors une approche en deux étapes. La première consiste à enregistrer, enregistrer des lots et des lots.
La seconde consiste à déterminer les principaux composants et leurs interfaces, et à définir dans quels cas d'erreur majeurs ces composants peuvent se trouver. Vous pouvez ensuite vous connecter de manière plus visible lorsque l'une de ces erreurs (la façon dont vous traitez l'erreur en interne vous appartient). - les exceptions ou codes d'erreur ne font aucune différence ici). Un utilisateur verra alors généralement l'erreur et consultera les journaux pour des informations plus détaillées.
La même approche est utilisée pour les serveurs Web et votre exemple de code d'erreur http. Si l'utilisateur voit un 404 et le signale au support, il recherchera dans les journaux les détails de ce qui se passait, quelle page a été visitée, quand et glanera toutes les autres informations qu'il pourra, d'où qu'elles aient un sens , être dans la base de données, le réseau ou l'application.
J'irais pour des exceptions personnalisées avec des noms descriptifs et des messages clairs et les jetterais. Il est beaucoup plus facile d'utiliser l'infrastructure d'exception existante d'un langage que de prendre en charge la transmission des codes d'erreur et leur interprétation.