EnterpriseLibrary ExceptionHandling n'écrit pas dans mon fichier journal

Question

La journalisation des exceptions de l'entreprise & est activée dans mon application Web. Le web.config est configuré pour que tout fonctionne. Il a déjà fonctionné sur d'autres serveurs car le fichier trace.log qui se trouve à la racine de l'application contient des informations de trace. J'ai effacé mon fichier trace.log sur ma machine locale pour tester qu'il fonctionnait lorsque j'ai des exceptions. J'ai créé une page de test qui génère une exception. J'appelle alors ExceptionPolicy.HandleException (ex, "Exception Policy") et relance si nécessaire. Mon fichier trace.log reste vide, donc je ne peux pas comprendre pourquoi cela ne fonctionne pas. Je suis assez nouveau à ce sujet, mais je sais que cela a déjà fonctionné. Ce dont je ne suis pas sûr, est-ce que l'exception sera écrite dans le fichier journal de toute façon, ou seulement à la suite de l'appel HandleException()?

J'ai du mal à déboguer pourquoi cela ne fonctionne pas.

Answer 1

J'ai travaillé sur ceci à la fin et documente pour m'aider & d'autres. C'était à cause de mon manque de connaissance de comment cela fonctionne et aussi le code étrange que nos entrepreneurs ont écrit.

Fondamentalement notre pile est constituée d'

couche de DA de la couche BO couche App

La couche BO accède à la DA. Si quelque chose ne va pas, alors il est géré dans un Try/Catch. Dans la capture, il appelle ExceptionPolicy.HandleException() et renvoie la valeur booléenne rethrow. Cependant, il ne vérifie pas cette valeur pour effectuer un autre lancement, ce qui signifie que l'erreur n'est pas propagée à l'exécution d'erreur ASP.NET. Etrangement, ils définissent un indicateur IsExceptionGenerated sur l'objet BO qui est ensuite vérifié sur la couche App. La couche App redirige ensuite vers '~ \ error.aspx'.

J'ai modifié cela pour que la politique soit vérifiée et que l'exception soit renvoyée. Mais il n'y a nulle part où l'exécution a été enregistrée. Je ne veux pas de charges de journalisation dispersées dans l'application juste avant la redirection vers error.aspx. Par conséquent, j'ai ajouté le gestionnaire d'erreur global.asax pour consigner l'erreur. Je peux également supprimer toutes les redirections et laisser le web.config spécifier la page directe à la page d'erreur en utilisant la section CustomErrors.

Cela semble maintenant fonctionner!

Je voudrais savoir si response.redirects ("error.aspx") est une mauvaise pratique tout au long de mon application. Je voudrais savoir ce qu'ils pensaient quand ils ont écrit ceci. Je peux comprendre que, parfois, vous vouliez faire une erreur, et que vous continuiez parfois avec élégance tout en continuant à le suivre, mais cela peut sûrement être géré en utilisant différentes stratégies d'exception.

Vous avez des idées?