Classification d'erreur standardisée & amp; Manipulation

Question

Je dois normaliser la manière dont je classifie et gère les erreurs / exceptions de manière "appropriée".

J'utilise actuellement un processus par lequel je signale les erreurs à une fonction en transmettant un numéro d'erreur, un code de gravité, des informations de localisation et une chaîne extra-info. Cette fonction retourne boolean true si l'erreur est fatale et que l'application devrait mourir, false sinon. Dans le cadre de ce processus, outre le retour visuel à l'utilisateur, la fonction enregistre également les erreurs de plus d'un niveau de gravité.

numéro-erreur indexe un tableau de chaînes expliquant le type d'erreur, par exemple: 'Accès au fichier', 'Entrée utilisateur', 'Création de threads', 'Accès réseau', etc. Le code de gravité est un OU binaire de 0 , 1,2 ou 4, 0 = informatif, 1 = utilisateur_retry, 2 = impossible à compléter, 4 = impossible_continuer. Lieu-info is module & amp; fonction, et Extra-info correspond aux valeurs de paramètre et de variable locale.

Je souhaite en faire un moyen standard de gestion des erreurs, que je peux mettre dans une bibliothèque et réutiliser dans toutes mes applications. J'utilise principalement le C / C ++ sous Linux, mais j'aimerais également utiliser la bibliothèque résultante avec d'autres langages / plates-formes.

• Une idée est d'étendre le type d'erreur tableau pour indiquer une valeur par défaut comportement pour un niveau de gravité donné, mais si cela devenait alors la les mesures prises et ne pas donner d'options à l'utilisateur?

• Ou: cette extension devrait-elle être une sous-tableau d'options que l'utilisateur besoin de choisir? Le problème avec c'est que les options seraient de nécessité d'être généralisé options liées à la programmation qui peuvent très bien baffle complètement un utilisateur final.

• Ou: chaque application utilisant le La routine error-lib passe le sien tableau des erreurs ou par défaut comportements - mais cela vaincra le but de la bibliothèque ...

• Ou: les niveaux de gravité doivent-ils être géré dans chaque application?

Ou: que proposez-vous? Comment gérez-vous les erreurs? Comment puis-je améliorer cela?

Answer 1

La façon dont vous gérez les erreurs dépend vraiment de l'application. Une application Web a un mécanisme de capture des erreurs différent de celui d'une application de bureau, et les deux diffèrent radicalement d'un système de messagerie asynchrone.

Cela étant dit, la pratique courante en matière de traitement des erreurs consiste à le traiter au niveau le plus bas possible, là où il peut être traité. Cela signifie généralement la couche d'application ou l'interface graphique.

J'aime les niveaux de gravité. Peut-être que vous pouvez avoir une bibliothèque de collection d’erreurs enfichable avec différents fournisseurs de sortie d’erreur et fournisseur de niveau de gravité.

Les fournisseurs de sortie peuvent inclure des éléments tels que logginProvider et IgnoreErrorsProvider. Les fournisseurs de gravité seraient probablement mis en œuvre par chaque projet, car les niveaux de gravité sont généralement déterminés par le type de projet dans lequel ils se produisent. (Par exemple, les problèmes de connexion réseau sont plus graves pour une application bancaire que pour un système de gestion de contacts).