Je suis en train d'écrire un ensemble de classes d'enregistrement d'erreurs qui vont enregistrer dans un fichier, un journal d'événements, etc. Quel traitement des exceptions doit être effectué dans ces classes ? Par exemple, disons que j'ai une méthode LogError, qui est appelée par les gestionnaires d'exceptions, et qui écrit dans un fichier. Quelle est la meilleure chose à faire en cas d'erreur ? Il est évident que je dois rendre ces méthodes aussi sûres que possible, mais des problèmes peuvent toujours survenir.
Réponses
Trop de publicités?
En général, j'envoie à stderr autant d'informations que possible dans ce cas, souvent à la fois l'erreur/exception dans le code de journalisation, et le journal/erreur/exception original. De cette façon, il y a une chance de reproduire le problème ou de le comprendre.
Si l'écriture sur stderr échoue, il est temps d'abandonner - soit en l'ignorant, soit en terminant entièrement l'application.
Miguel Ping
Points
9013
Pourquoi n'utilisez-vous pas un mécanisme de journalisation existant tel que log4j/log4net/log4php/log4* ? Ces outils ont probablement réglé ces détails.
Par ailleurs, si vous exécutez votre code à l'intérieur d'un conteneur (par exemple, Tomcat), même si vous lancez une exception dans le gestionnaire d'exceptions, le conteneur l'attrape et l'affiche. Comme Douglas Leeder l'a dit, vous pouvez attraper toutes les exceptions dans le gestionnaire d'exception et les envoyer à syserr.
Nir
Points
18250
Cela dépend de la finalité de la journalisation, s'il s'agit d'une journalisation de débogage, je vais avaler l'exception et continuer parce que je ne veux jamais que l'application échoue en production à cause d'aides au débogage, d'un autre côté, si j'enregistre dans le journal d'audit d'une application bancaire, je suppose que le client va être contrarié si l'application continue à fonctionner sans audit.
Eric Rcoh
Points
1
Vous pouvez mettre en œuvre l'audit et le traitement des exceptions en tant que services. La journalisation de l'audit au niveau de l'application nécessite des données d'état sur chaque transaction commerciale. La possibilité 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'invocation du service. Pour cela, chaque service doit envoyer un message d'état à des étapes critiques de la transaction commerciale. Vous pouvez ensuite construire un visualiseur en temps réel pour corréler les messages d'état (sur la base de la sémantique du message - par exemple l'ID de la transaction) avec les services de l'application composite. Vous obtenez ainsi une vue de bout en bout de la transaction commerciale pour la gestion des accords de niveau de service, le dépistage des erreurs et la détermination des problèmes.
Un service d'audit peut alors être implémenté comme une machine à état qui peut consommer et enregistrer des messages en fonction de critères définis dans sa configuration. Un gestionnaire d'exception générique peut également utiliser le service d'audit pour prendre en charge une vue centralisée des problèmes qui surviennent dans l'architecture SOA d'entreprise - pour prendre en charge la surveillance basée sur les exceptions. Toute condition qui ne devrait pas se produire dans la solution est instrumentée pour envoyer un message d'exception au service de gestion des exceptions. le gestionnaire d'exception.
