Quand commencer à écrire la gestion des exceptions, la journalisation

Quand commencez-vous à écrire votre code de gestion des exceptions? Quand commencez-vous à écrire des instructions de journalisation.

Pour élaborer cette question, supposons que nous sommes sur la plate-forme .NET avec la journalisation log4net mais n'hésitez pas à répondre de manière générique.

Solution: un projet Windows Forms. Projets: UI, BusinessRules, DataHandlers

Alors, allez-vous écrire vos DataHandlers qui font d'abord vos manipulations de données telles que Créer, Lire, Mettre à jour, Supprimer.

Ensuite, suivez-le avec vos règles commerciales

Et puis votre interface utilisateur ou toute autre permutation de ce qui précède.

Testez votre application pour la fonctionnalité.

Et puis commencez à écrire votre code de gestion des exceptions et enfin votre code de journalisation?

Quel est le bon moment pour commencer à écrire votre code de gestion des exceptions?

PS: Dans le livre Clean Code , ils disent d'abord Écrivez votre bloc try-catch-finally . Cela m'a incité à poser cette question.

Vous écrivez votre code de gestion des exceptions lorsque vous écrivez ce qui appelle quelque chose qui pourrait provoquer des exceptions.

Par exemple, lorsque vous écrivez quelque chose qui envoie des données à un réseau, vous devez également écrire le code qui gère les délais d'attente de connexion. L'exception est directement liée à ce que vous faites et le travail est frais dans votre esprit.

D'un autre côté, si vous écrivez un analyseur qui déclenche des exceptions lorsqu'il rencontre une unité de données de protocole mal formée, vous ne pouvez pas écrire de code de gestion des exceptions pour les exceptions que l'analyseur produit . (Mais bien sûr, vous écrivez des tests pour montrer comment et quand et pourquoi l'analyseur lève des exceptions!)

La raison derrière la suggestion d'écrire d'abord votre try-catch-finally est double: enfin, pour nettoyer les ressources que la fonction crée / consomme, et l'écriture du catch est un bon rappel que les fonctions que vous appelez peuvent échouer, et vous devez gérer (si nécessaire) ces échecs.

J'ai tendance à ajouter la journalisation après coup. Je ne sais pas si c'est sage, mais c'est juste ce qui a fonctionné pour moi. Au fur et à mesure que je commence à exécuter des tests d'acceptation et autres, et à commencer à rencontrer des problèmes, j'ajoute la journalisation afin de pouvoir suivre les erreurs. (Et puis je laisse la connexion.)

D'après mon expérience, si vous n'écrivez pas de code avec la gestion des erreurs et la journalisation appropriées depuis le début, cela ne se fera pas en raison de contraintes de temps. Les efforts de développement les plus réussis sur lesquels j'ai travaillé ont commencé avec le temps passé à déterminer la structure d'application de base, y compris la norme de codage, la façon dont les erreurs seraient gérées, la journalisation, l'architecture de base et les outils de test.

Sinon, vous constaterez que vous avez des tâches pour la version 2.0 comme "Améliorer la gestion des erreurs" et "créer un système de journalisation". Ceux-ci seront coupés au profit de nouvelles fonctionnalités, et parce que vous avez «trop à faire», corrigez tous ces bugs dans les cas d'erreur auxquels vous n'avez pas pensé. (Ce qui prend une éternité, car vous n'avez pas de système d'enregistrement.

Cela dépend de ce que vous faites

pour les exceptions:

Si vous écrivez quelque chose qui est susceptible d'avoir des erreurs ou quelque chose où il y a de bons points de niveau supérieur pour laisser des exceptions se multiplier pour les écrire au fur et à mesure.

Si vous écrivez quelque chose qui nécessite des performances et a une faible possibilité d'erreurs, il manque un endroit significatif pour placer les gestionnaires d'erreurs écrire les gestionnaires d'erreurs où les tests prouvent que vous en avez besoin.

Dans les deux cas, si vous n'avez rien à voir avec l'erreur, envisagez de le laisser bouillonner (pas de gestionnaire)

pour la journalisation:

Si vous avez besoin d'une piste d'audit, vous devez d'abord écrire la journalisation. Si vous laissez les erreurs se propager jusqu'au sommet, vous devez également fournir une journalisation afin que le journal puisse être capturé.

En dehors de ces cas, je n'ajoute généralement la journalisation qu'aux endroits où le test / l'utilisation prouve que cela est nécessaire et je fais généralement une option pour le configurer une fois que j'en ai fini.

Vous pouvez implémenter l'audit et la gestion des exceptions en tant que services. La journalisation d'audit au niveau de l'application nécessite des données d'état sur chaque transaction commerciale. La capacité de surveiller une application dans un contexte commercial ou transactionnel nécessite une interface de surveillance au sein du service pour envoyer des messages détaillant l'état de la transaction spécifique à l'appel du service. Cela nécessite que chaque service envoie un message d'état aux étapes critiques de la transaction commerciale. Vous pouvez ensuite créer une visionneuse en temps réel pour corréler les messages d'état (basés sur la sémantique du message - par exemple l'ID de transaction) avec les services au sein de l'application composite. Cela fournit une vue de bout en bout de la transaction commerciale pour la gestion du SLA, le suivi des défauts et la détermination des problèmes.

Un service d'audit peut ensuite être implémenté comme une machine d'état qui peut consommer et enregistrer des messages en fonction de critères définis dans sa configuration. Un gestionnaire d'exceptions générique peut également utiliser le service d'audit pour prendre en charge une vue centralisée des problèmes qui se produisent dans la SOA d'entreprise - pour prendre en charge la surveillance basée sur les exceptions. Toute condition à ne pas se produire dans la solution est instrumentée pour envoyer un message d' exception au gestionnaire d'exceptions.

Écrivez-le quand vous en avez besoin, mais concevez-le dès le départ.

En d'autres termes: assurez-vous qu'il existe un moyen de gérer cette capacité de journalisation et ajoutez la fonctionnalité réelle d'écrous et de boulons (quels messages il enregistre) plus tard si le besoin s'en fait sentir. Sur les exceptions, ajoutez la capture (et enfin si vous l'avez) avant d'écrire le lancer. Cela vous aidera à ne pas en oublier un et à vous éviter une itération ou au pire un bug / crash.