Gestion des erreurs ASP.NET

Question

Dans mes applications asp.net, j'ai généralement utilisé le gestionnaire d'événements global Application_Error pour consigner l'erreur et rediriger l'utilisateur vers une page d'erreur conviviale.

Cependant, j'ai lu environ ELMAH et bien que cela semble intéressant, Application_Error semble être l'approche la plus simple.

J'ai lu d'autres questions où les gens, y compris moi-même, ont suggéré d'une façon ou d'une autre. Ce que je me demande, c'est s'il y a un avantage significatif à utiliser l'un plutôt que l'autre et pourquoi?

Answer 1

Elmah est un projet fantastique et nous l'utilisons pour toutes nos applications ASP.NET. Non seulement il enregistre les erreurs non gérées pour vous, il saisit la page entière originale que l'utilisateur a vu, qui contient beaucoup de détails pour vous.

Il dispose d'un support e-mail, des flux RSS (à la fois détaillés et digérer) et dispose d'une console attrayante.

Pour 3 lignes dans config et une référence dll, je dirais que c'est un slam dunk.

Answer 2

Je suppose que le principal inconvénient de ELMAH est qu'il pourrait être trop lourd pour ce dont vous avez besoin. Si vous consignez et stockez plus d'informations que vous ne le feriez dans votre propre implémentation, cela représente un surcoût inutile pour le stockage et le traitement. Vous devez également réfléchir à la façon dont vous sécurisez l'accès à la console d'ELMAH car ces détails d'exception peuvent contenir des détails juteux de votre application (cela ne doit pas être difficile, mais c'est une inquiétude que vous n'aviez pas auparavant). D'autre part, votre propre implémentation va probablement croître pour enregistrer toutes les informations supplémentaires une fois que vous décidez qu'un bug tenace l'exige, et vous souciez-vous vraiment de raser des fractions de seconde du temps qu'il faut pour le page d'erreur à afficher? Les chances sont que vous finiriez par construire votre propre version d'ELMAH, alors pourquoi ne pas simplement utiliser ELMAH et vous épargner du temps.

Je recommanderais que si vous voulez écrire votre propre journal des erreurs plutôt que d'utiliser ELMAH, vous le placez au moins dans un module plutôt que directement dans Application_Error dans global.asax. Abonnez-vous simplement à l'événement Error de l'application dans la méthode Init de votre module, et vous pouvez facilement réutiliser votre code de gestion des erreurs dans une autre application avec une ligne dans web.config. Je trouve également utile de gérer toute journalisation des exceptions via la surveillance de l'état de santé d'ASP.NET. Cela facilite le contrôle du type et du niveau de journalisation dans web.config, et permet également la journalisation des exceptions qui ont été traitées dans un try ... catch sans aller jusqu'à Application_Error. Créez une classe HandledExceptionEvent personnalisée qui étend WebRequestErrorEvent et vous pouvez créer et déclencher ces événements dans n'importe quel bloc catch où vous aimeriez vraiment savoir que l'exception s'est produite même si elle a été gérée.