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 :
Concernant l'élément de paramètre
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 :
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
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 à