Pour une application Web, les erreurs sont inévitables, nous devons donc prendre des précautions et prévoir une gestion appropriée des erreurs possibles. En fait, un bon mécanisme de gestion des erreurs est un critère important pour mesurer la qualité des applications Web. Imaginez simplement, lorsque l'utilisateur entre accidentellement une mauvaise URL dans le navigateur ou lorsque l'utilisateur fournit des informations provoquant une erreur du programme, si nous ne gérons pas ces situations, nous autorisons les pages d'erreur 404 ou 500 ou même les informations de la pile. est présenté devant les utilisateurs, ce qui effrayera sans aucun doute certains utilisateurs. Par conséquent, lorsque nous développons des applications Web, nous devons avoir une compréhension complète du mécanisme de gestion des erreurs.
Revenons à ASP.NET et posons deux questions auxquelles tout le monde doit réfléchir : combien de mécanismes de gestion des erreurs ASP.NET nous fournit-il ? Si plusieurs mécanismes de gestion d’erreurs sont utilisés en même temps, existe-t-il une certaine priorité entre eux ? En gardant cette question à l’esprit, examinons d’abord notre fichier Web.Config le plus courant :
<?xml version="1.0"?>
<configuration>
<système.web>
<customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="Error403.htm" />
<error statusCode="404" redirect="Error404.htm" />
</customErreurs>
</system.web>
</configuration>
Concernant l'élément de paramètre <customErrors>, je pense qu'il n'est pas nécessaire d'en dire plus. Pour plus de détails, veuillez vous référer à MSDN. Le premier mécanisme de gestion des erreurs - utilisant l'élément de configuration <customErrors> de Web.Config devrait être le plus couramment utilisé.
Examinons ensuite un autre fichier également très couramment utilisé : Global.asax. Lorsque vous évoquez ce document, à quoi pensez-vous ? Oui, ce sont des événements liés aux deux objets majeurs de l'application Web (Application et Session). Parmi ces événements, il existe un événement lié à une erreur qui appartient à la catégorie Application - Erreur, et la méthode de traitement des événements correspondante est Application_Error. Comme son nom l'indique, cette méthode de gestion des événements sera appelée lorsqu'une erreur au niveau de l'application se produit. Vous pouvez donc ajouter du code dans cette méthode pour gérer l'erreur, comme indiqué ci-dessous :
protected void Application_Error(object sender, EventArgs e) {
Exception objErr = Server.GetLastError().GetBaseException();
Réponse.Write("Erreur :" + objErr.Message);
Server.ClearError();
}
Ici, tout le monde devrait faire attention à l'utilisation de Server.ClearError() dans la dernière ligne de code. Pourquoi cette ligne de code devrait-elle être utilisée ? Que se passe-t-il si vous ne l'utilisez pas ? Ici, je vais réessayer. Eh bien, le deuxième mécanisme de gestion des erreurs - utilisant la méthode de gestion des événements Application_Error dans Global.asax a également fait ses débuts.
Les deux méthodes de gestion des erreurs ci-dessus peuvent être considérées comme globales. L'une est dérivée du fichier de configuration de l'application et l'autre est la méthode de gestion des événements du fichier Global.asax qui doit être placé dans le répertoire racine de l'application. L'opposé du global est le local, nous nous demandons donc naturellement : existe-t-il un mécanisme de gestion des erreurs qui s'applique au local - à une certaine page ? La réponse est "oui", et il existe deux manières : en utilisant l'attribut ErrorPage et en utilisant la méthode de gestion des événements Page_Error. Pour le premier mécanisme, vous pouvez définir la propriété ErrorPage presque à tout moment pour déterminer vers quelle page sera redirigée lorsqu'une erreur se produit sur la page ; pour le deuxième mécanisme, elle est très similaire à la méthode de gestion des événements Application_Error, sauf que Mais le moment du déclenchement est différent. Voici deux exemples spécifiques :
<script language="C#" runat="server">
protected void Page_Load (expéditeur de l'objet, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</script>
protected void Page_Error (expéditeur de l'objet, EventArgs e) {
Exception objErr = Server.GetLastError().GetBaseException();
Réponse.Write("Erreur :" + objErr.Message);
Server.ClearError(); //Faites également attention à l'utilisation de ce code
}
À ce stade, les quatre mécanismes de gestion des erreurs sont tous apparus et il est temps de les classer. Trier de priorité élevée à faible : méthode de gestion des événements Page_Error > propriété ErrorPage > méthode de gestion des événements Application_Error > élément de configuration <customErrors>. Bien que le classement soit ainsi, il existe une relation subtile entre les classements. Tout d'abord, pour que l'attribut ErrorPage fonctionne, l'attribut mode dans l'élément de configuration <customErrors> doit être défini sur "On", deuxièmement, bien que la méthode de traitement d'événement Page_Error soit classée en premier, si la méthode Server.ClearError() est classée ; manquant Si tel est le cas, la gestion des erreurs de priorité inférieure sera toujours déclenchée. Cela est également vrai pour la méthode de gestion des événements Application_Error. L'ordre est organisé, mais l'ordre n'est pas la question la plus importante. On peut même dire que c'est une question qui n'a pas beaucoup de sens, car dans de nombreux cas, on ne peut pas mélanger ces quatre mécanismes de traitement. Je pense que le problème le plus important est de savoir comment choisir ces mécanismes de gestion des erreurs. Concernant cette question, j'espère que des amis expérimentés pourront partager leurs opinions.
Bon, c'est tout pour présenter les quatre mécanismes de gestion des erreurs d'ASP.NET, et il est temps de parler de certains de mes propres sentiments. Les concepteurs d'ASP.NET ont en effet fait une réflexion approfondie du point de vue des développeurs, ils nous proposent donc jusqu'à quatre mécanismes de gestion des erreurs parmi lesquels choisir, ce qui est louable. Mais pour paraphraser un slogan publicitaire, trop de choses prêtent à confusion, nous serons aussi un peu étourdis par tant de mécanismes de gestion des erreurs. En comparant la gestion des erreurs dans le domaine J2EE, nous pouvons constater qu'elle est relativement simple. Le premier est le paramètre correspondant à <customErrors>. On peut également retrouver des éléments de configuration similaires du fichier web.xml le plus couramment utilisé dans les projets J2EE : <errorPage> d'autre part, dans le domaine de J2EE, Page n'est pas une entité importante et event Le modèle de pilote n'est pas nécessaire, donc je ne trouve vraiment pas le mécanisme de traitement correspondant pour les méthodes Application_Error et Page_Error ; enfin, dans le domaine de J2EE, l'accent est davantage mis sur la requête et la réponse lorsqu'une erreur se produit dans le traitement logique. , Nous pouvons facilement distribuer la requête au module de gestion des erreurs correspondant via RequestDispatcher. En fait, il s'agit d'une méthode de traitement très flexible. Les amis intéressés voudront peut-être en savoir plus.