Comment gérer les exceptions pendant un cycle de vie de demande ASP.NET

Question

Cette question est en quelque sorte liée à Handle URI hacking gracefully in ASP.NET en ce qu'il concerne également la meilleure façon de gérer les exceptions qui se produisent pendant un cycle de vie de demande ASP.NET. J'ai trouvé un moyen de gérer la plupart des exceptions gracieusement, mais j'ai constaté que certaines exceptions se produisent si tard dans la demande qu'il est impossible de faire des choses comme Server.Transfer pour compresser toute la logique de présentation d'erreurs dans sa propre page.

Donc, je dois gérer l'exception à l'intérieur de l'événement Application_Error à la place, et faire Response.Write s et autres joyeusetés. C'est moche. Je comprends que dans certaines circonstances, le flux de réponse aurait déjà pu être vidé, donc le transfert de la demande n'est pas vraiment une option. Ce que je veux demander, c'est s'il y a quelqu'un qui a trouvé une solution élégante à ce problème?

En outre, je trouve difficile de savoir quand je peux gérer l'exception gracieusement en transférant la demande à une autre page et non. Quel est le meilleur moyen de savoir où se trouve le cycle de vie de la requête lorsqu'une exception se produit? Si cela se produit pendant le chargement et le rendu d'une page, Page_Error sera en mesure de le gérer et je n'ai pas eu de problème à faire Server.Transfer là encore. Mais si l'exception se produit soit trop tôt soit trop tard pour que le Page_Error l'attrape et que la bulle se mette à Application_Error, que dois-je faire pour savoir s'il est tôt ou tard?

S'il est tard dans le cycle de vie, je vais probablement faire Response.Write directement à partir Application_Error, mais si elle est trop tôt je peux faire Server.Transfer. Le problème est qu'essayer de faire Server.Transfer lui-même provoquera une exception si c'est aussi dans la demande de le faire. Donc, y a-t-il une énumération globale ou quelque chose de similaire qui indiquera s'il est trop tard pour faire des choses créatives avec la réponse ou non?

Answer 1

J'ai utilisé cette approche pour attraper toutes les erreurs générées, soit dans les contrôles web ou pages. Tout ce qu'il vous faut faire est d'hériter d'une classe de base (une pour les pages et une pour les commandes userc) chaque page ou usercontrol peut implémenter sa propre méthode HandleException et faire tout ce qu'il faut faire. code complet ici:

Transparent generic exception handling for asp.net/MOSS2007 (with code)

Answer 2

Je pense que mon conseil pour cela d'utiliser la surveillance de la santé ASP.NET avec WMI fournisseur d'événements pour les erreurs:

Voici un comment.

http://msdn.microsoft.com/en-us/library/ms178713.aspx

Hope this helps:

Andrew

Answer 3

Je vous suggère d'utiliser la configuration de asp.net d'avoir une page d'erreur générale pour les exceptions non gérées. A partir de l'échantillon web.config

<!-- 
     The <customErrors> section enables configuration 
     of what to do if/when an unhandled error occurs 
     during the execution of a request. Specifically, 
     it enables developers to configure html error pages 
     to be displayed in place of a error stack trace. 

    <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm"> 
     <error statusCode="403" redirect="NoAccess.htm" /> 
     <error statusCode="404" redirect="FileNotFound.htm" /> 
    </customErrors> 
    --> 

Sur le gestionnaire général, connectez-vous à l'exception, et laissez asp.net faire la redirection.

Si vous voulez continuer votre approche client, je vous suggère de regarder la source disponible asp.net et de vérifier comment elle fonctionne.