Un cadre de journalisation doit-il vraiment engloutir les échecs de journalisation?

Question

Bien qu'il ne fasse aucun doute qu'un enregistreur ne devrait pas provoquer le plantage d'une application, alors que je corrigeais mon enregistreur d'entreprise, je ne savais pas comment avaler correctement une exception lancée par le cadre de journalisation lui-même. En métacode:

public void write(TMessage message) 
{ 
    try 
    { 
     writeUnsafely(message); 
    } 
    catch(Exception loggingException) 
    { 
     // what should I do here? 
    } 
} 

Dois-je ignorer le loggingException (comme log4net fait) ou devrais-je laisser le code client choisir comment gérer (peut-être avec un gestionnaire configurable)?

Answer 1

NLog a une option de configuration qui permet de vous connecter à configurer pour lancer des exceptions (ou non):

https://github.com/nlog/nlog/wiki/Configuration-file

(Voir la section Exploitation forestière Dépanner).

Il semble que donner au code client une chance de le gérer est un choix raisonnable. Une recommandation sur la façon dont un programme client doit gérer l'exception peut être utile à inclure dans votre documentation (si vous choisissez d'implémenter une telle fonctionnalité). Un exemple pourrait être quelque chose comme "Vous pouvez attraper le LoggingException dans le gestionnaire d'exception non géré de votre application."

Answer 2

C'est entièrement à vous, mais quoi que vous décidiez, documentez-le. Mis à part ajouter de la complexité à la fois dans le code et pour les utilisateurs, je ne vois pas de mal à le rendre configurable.

Vous pouvez simplement écrire du code parfait qui n'a aucun bogue et qui ne lève aucune exception. ;-)