Méthode recommandée pour créer un modèle de codes d'erreur pour un projet d'entreprise en C # [fermé]

Je travaille sur un projet d'entreprise qui sera déployé dans de nombreuses PME et entreprises.
La prise en charge de ce projet serait difficile et je souhaite donc créer un modèle de codage pour les erreurs ( comme les codes d'état HTTP ). Cela permettra aux personnes du service d'assistance de se référer à des documents et de résoudre les problèmes le plus rapidement possible.

Quelles sont les meilleures pratiques et recommandations pour le 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 indiquant 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 conseillerais contre cela. Les exceptions constituent le moyen moderne de signaler les erreurs, et il n’ya aucune raison pour qu’elles ne contiennent pas de code d’erreur.

Voici comment je l’organiserais (notez que les points 2 à 6 sont indépendants de la langue):

1. Utilisez un type d'exception personnalisé avec une ErrorCodepropriété supplémentaire . La capture dans la boucle principale signalera ce champ de la manière habituelle (fichier journal / erreur pop-up / réponse d'erreur). Utilisez le même type d'exception dans tout votre code.
2. Ne commencez pas à 1 et n'utilisez pas de zéros à gauche. Conservez tous les codes d'erreur à la même longueur, de sorte qu'un mauvais code d'erreur est facile à repérer. Commencer à 1000 est généralement suffisant. Ajoutez peut-être un «E» à la base pour les rendre clairement identifiables pour les utilisateurs (particulièrement utile lorsque le support technique doit indiquer aux utilisateurs comment détecter le code d'erreur).
3. Conservez une liste de tous les codes d'erreur, mais ne le faites pas dans votre code . Conservez 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 support technique doit avoir une liste séparée sur son propre wiki.
4. N'essayez pas d'imposer une structure aux 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 .
5. Attribuez à chaque lancer dans votre code un code séparé. Même si vous pensez que c'est la même cause, le support technique peut avoir besoin de faire différentes choses dans différents cas. Il est plus facile pour eux d'avoir "E1234: See E1235" dans leur wiki, plutôt que d'amener l'utilisateur à avouer ce qu'il a mal fait.
6. Fractionner les codes d'erreur si le service d'assistance le demande. Une simple if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");ligne dans votre code peut faire gagner une demi-heure au service d’assistance.

Et n'oubliez jamais que les codes d'erreur ont pour but de simplifier la vie du service d'assistance .

Vous devez d'abord isoler les zones où des erreurs peuvent survenir et sont visibles pour l'utilisateur. Ensuite, vous pouvez les documenter. C'est si simple.

Eh bien, c'est simple en théorie… en pratique, des erreurs peuvent se produire partout, et les signaler peut transformer un code agréable en un monstre de journalisation, de lancement et de traitement des exceptions et de transmission des valeurs de retour.

Je recommanderais alors une approche en 2 étapes. La première consiste à enregistrer, connectez-vous des lots, des lots.

Deuxièmement, il faut déterminer les principaux composants et leurs interfaces, ainsi que les cas d’erreur majeurs dans lesquels 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 gérez l’erreur en interne dépend de vous. - les exceptions ou les codes d'erreur ne font aucune différence ici). Un utilisateur verra généralement l'erreur et consultera les journaux pour obtenir 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 une 404 et la signale au support, il consultera dans les journaux les détails de ce qui se passait, de la page visitée, de la date et glanera toute autre information possible, là où elle a un sens. , être dans la base de données, le réseau ou l’application.

Je voudrais aller pour les exceptions personnalisées avec des noms descriptifs et des messages clairs et jette ceux-ci. Il est beaucoup plus facile d'utiliser l'infrastructure d'exception existante d'un langage que de prendre en charge le transfert de codes d'erreur et leur interprétation.