Affichage d’une page d’erreur personnalisée (VB)
par Scott Mitchell
Que voit l’utilisateur lorsqu’une erreur d’exécution se produit dans une application web ASP.NET ? La réponse dépend de la configuration customErrors> du <site web. Par défaut, un écran jaune disgracieux s’affiche aux utilisateurs indiquant qu’une erreur d’exécution s’est produite. Ce tutoriel montre comment personnaliser ces paramètres pour afficher une page d’erreur personnalisée esthétique qui correspond à l’apparence de votre site.
Introduction
Dans un monde parfait, il n’y aurait pas d’erreurs d’exécution. Les programmeurs écrivent du code avec un bogue et une validation d’entrée utilisateur robuste, et les ressources externes telles que les serveurs de base de données et les serveurs de messagerie ne sont jamais mises hors connexion. Bien sûr, en réalité, les erreurs sont inévitables. Les classes dans le .NET Framework signalent une erreur en lisant une exception. Par exemple, l’appel de la méthode Open d’un objet SqlConnection établit une connexion à la base de données spécifiée par une chaîne de connexion. Toutefois, si la base de données est en panne ou si les informations d’identification dans la chaîne de connexion ne sont pas valides, la méthode Open lève un SqlException. Les exceptions peuvent être gérées par l’utilisation de Try/Catch/Finally blocs. Si le code dans un Try bloc lève une exception, le contrôle est transféré vers le bloc catch approprié où le développeur peut tenter de récupérer à partir de l’erreur. S’il n’existe aucun bloc catch correspondant, ou si le code qui a levé l’exception n’est pas dans un bloc try, l’exception percole dans la pile des appels dans la recherche de Try/Catch/Finally blocs.
Si l’exception s’affiche jusqu’à l’ASP.NET runtime sans être gérée, l’événement de Error la HttpApplication classe est déclenché et la page d’erreur configurée s’affiche. Par défaut, ASP.NET affiche une page d’erreur affectueusement appelée Écran jaune de la mort (YSOD). Il existe deux versions de YSOD : l’une affiche les détails de l’exception, une trace de pile et d’autres informations utiles aux développeurs débogueant l’application (voir la figure 1) ; l’autre indique simplement qu’il y a eu une erreur d’exécution (voir la figure 2).
Les détails de l’exception YSOD sont très utiles pour les développeurs déboguant l’application, mais l’affichage d’un YSOD aux utilisateurs finaux est peu pratique et non professionnel. Au lieu de cela, les utilisateurs finaux doivent être dirigés vers une page d’erreur qui maintient l’apparence du site avec une prose plus conviviale décrivant la situation. La bonne nouvelle est que la création d’une telle page d’erreur personnalisée est assez facile. Ce tutoriel commence par un aperçu d’ASP. Pages d’erreur différentes de NET. Il montre ensuite comment configurer l’application web pour afficher aux utilisateurs une page d’erreur personnalisée en cas d’erreur.
Examen des trois types de pages d’erreur
Lorsqu’une exception non gérée survient dans une application ASP.NET l’un des trois types de pages d’erreur s’affiche :
- La page d’erreur Détails de l’exception Écran jaune de la mort,
- La page d’erreur d’erreur d’exécution de l’erreur de décès, ou
- Page d’erreur personnalisée
La page d’erreur que les développeurs connaissent le plus est le YSOD Détails de l’exception. Par défaut, cette page s’affiche pour les utilisateurs qui visitent localement et est donc la page que vous voyez lorsqu’une erreur se produit lors du test du site dans l’environnement de développement. Comme son nom l’indique, le YSOD Détails de l’exception fournit des détails sur l’exception : le type, le message et la trace de pile. De plus, si l’exception a été levée par du code dans la classe code-behind de votre page d’ASP.NET et si l’application est configurée pour le débogage, le YSOD Détails de l’exception affiche également cette ligne de code (et quelques lignes de code au-dessus et en dessous).
La figure 1 montre la page YSOD Détails de l’exception. Notez l’URL dans la fenêtre d’adresse du navigateur : http://localhost:62275/Genre.aspx?ID=foo. Rappelez-vous que la Genre.aspx page répertorie les critiques de livres dans un genre particulier. Il nécessite que GenreId la valeur (a uniqueidentifier) soit passée via la chaîne de requête ; par exemple, l’URL appropriée pour afficher les critiques de fiction est Genre.aspx?ID=7683ab5d-4589-4f03-a139-1c26044d0146. Si une valeur non-estuniqueidentifier passée via la chaîne de requête (par exemple, « foo »), une exception est levée.
Remarque
Pour reproduire cette erreur dans l’application web de démonstration disponible en téléchargement, vous pouvez visiter Genre.aspx?ID=foo directement ou cliquer sur le lien « Générer une erreur d’exécution » dans Default.aspx.
Notez les informations sur les exceptions présentées dans la figure 1. Le message d’exception « Échec de la conversion lors de la conversion d’une chaîne de caractères en uniqueidentifier » est présent en haut de la page. Le type de l’exception, System.Data.SqlClient.SqlException, est également répertorié. Il y a également la trace de pile.
Figure 1 : Les détails de l’exception YSOD incluent des informations sur l’exception
(Cliquez pour afficher l’image en taille réelle)
L’autre type de YSOD est L’erreur d’exécution YSOD et est illustré dans la figure 2. L’erreur d’exécution YSOD informe le visiteur qu’une erreur d’exécution s’est produite, mais elle n’inclut aucune information sur l’exception qui a été levée. (Toutefois, il fournit des instructions sur la façon de rendre les détails d’erreur visibles en modifiant le Web.config fichier, ce qui fait partie de ce qui rend un tel YSOD non professionnel.)
Par défaut, l’erreur d’exécution YSOD s’affiche aux utilisateurs qui visitent à distance (via http://www.yoursite.com), comme en témoigne l’URL dans la barre d’adresse du navigateur dans la figure 2 : http://httpruntime.web703.discountasp.net/Genre.aspx?ID=foo. Les deux écrans YSOD différents existent parce que les développeurs souhaitent connaître les détails de l’erreur, mais ces informations ne doivent pas être affichées sur un site actif, car elles peuvent révéler des failles de sécurité potentielles ou d’autres informations sensibles à toute personne qui visite votre site.
Remarque
Si vous suivez et utilisez DiscountASP.NET comme hôte web, vous pouvez remarquer que l’erreur d’exécution YSOD ne s’affiche pas lorsque vous visitez le site en direct. Cela est dû au fait que DiscountASP.NET a ses serveurs configurés pour afficher les détails de l’exception YSOD par défaut. La bonne nouvelle est que vous pouvez remplacer ce comportement par défaut en ajoutant une <customErrors> section à votre Web.config fichier. La section « Configuration de la page d’erreur affichée » examine la <customErrors> section en détail.
Figure 2 : L’erreur d’exécution YSOD n’inclut aucun détail d’erreur
(Cliquez pour afficher l’image en taille réelle)
Le troisième type de page d’erreur est la page d’erreur personnalisée, qui est une page web que vous créez. L’avantage d’une page d’erreur personnalisée est que vous disposez d’un contrôle total sur les informations affichées à l’utilisateur, ainsi que sur l’apparence de la page ; la page d’erreur personnalisée peut utiliser les mêmes master page et les mêmes styles que vos autres pages. La section « Utilisation d’une page d’erreur personnalisée » décrit la création d’une page d’erreur personnalisée et sa configuration pour qu’elle s’affiche en cas d’exception non gérée. La figure 3 offre un aperçu de cette page d’erreur personnalisée. Comme vous pouvez le voir, l’apparence de la page d’erreur est beaucoup plus professionnelle que l’un des écrans jaunes de la mort présentés dans les figures 1 et 2.
Figure 3 : Une page d’erreur personnalisée offre une apparence plus personnalisée
(Cliquez pour afficher l’image en taille réelle)
Prenez un moment pour inspecter la barre d’adresse du navigateur dans la figure 3. Notez que la barre d’adresses affiche l’URL de la page d’erreur personnalisée (/ErrorPages/Oops.aspx). Dans les figures 1 et 2, les écrans jaunes de la mort sont affichés sur la même page d’où provient l’erreur (Genre.aspx). La page d’erreur personnalisée est transmise à l’URL de la page où l’erreur s’est produite via le aspxerrorpath paramètre de chaîne de requête.
Configuration de la page d’erreur affichée
Parmi les trois pages d’erreur possibles, laquelle est basée sur deux variables :
- Les informations de configuration dans la
<customErrors>section et - Indique si l’utilisateur visite le site localement ou à distance.
La <customErrors> section de Web.config a deux attributs qui affectent la page d’erreur affichée : defaultRedirect et mode. L'attribut defaultRedirect est facultatif. S’il est fourni, il spécifie l’URL de la page d’erreur personnalisée et indique que la page d’erreur personnalisée doit être affichée au lieu de l’erreur d’exécution YSOD. L’attribut mode est obligatoire et accepte l’une des trois valeurs suivantes : On, Offou RemoteOnly. Ces valeurs ont le comportement suivant :
On- indique que la page d’erreur personnalisée ou L’erreur d’exécution YSOD s’affiche à tous les visiteurs, qu’ils soient locaux ou distants.Off- spécifie que le YSOD Détails de l’exception s’affiche pour tous les visiteurs, qu’ils soient locaux ou distants.RemoteOnly- indique que la page d’erreur personnalisée ou L’erreur d’exécution YSOD s’affiche aux visiteurs distants, tandis que le YSOD Détails de l’exception s’affiche aux visiteurs locaux.
Sauf indication contraire, ASP.NET agit comme si vous aviez défini l’attribut mode sur RemoteOnly et que vous n’aviez pas spécifié de defaultRedirect valeur. En d’autres termes, le comportement par défaut est que le YSOD Détails de l’exception est affiché aux visiteurs locaux tandis que l’erreur d’exécution YSOD est affichée aux visiteurs distants. Vous pouvez remplacer ce comportement par défaut en ajoutant une <customErrors> section à votre application web Web.config file.
Utilisation d’une page d’erreur personnalisée
Chaque application web doit avoir une page d’erreur personnalisée. Il fournit une alternative plus professionnelle à L’erreur d’exécution YSOD, il est facile à créer, et la configuration de l’application pour utiliser la page d’erreur personnalisée ne prend que quelques instants. La première étape consiste à créer la page d’erreur personnalisée. J’ai ajouté un nouveau dossier à l’application Book Reviews nommé ErrorPages et j’y ai ajouté une nouvelle page ASP.NET nommée Oops.aspx. Faites en sorte que la page utilise la même page master que les autres pages de votre site afin qu’elle hérite automatiquement de la même apparence.
Figure 4 : Créer une page d’erreur personnalisée
Ensuite, passez quelques minutes à créer le contenu de la page d’erreur. J’ai créé une page d’erreur personnalisée plutôt simple avec un message indiquant qu’il y avait une erreur inattendue et un lien vers la page d’accueil du site.
Figure 5 : Concevoir votre page d’erreur personnalisée
(Cliquez pour afficher l’image en taille réelle)
Une fois la page d’erreur terminée, configurez l’application web pour utiliser la page d’erreur personnalisée au lieu de L’erreur d’exécution YSOD. Pour ce faire, spécifiez l’URL de la page d’erreur dans l’attribut de la <customErrors>defaultRedirect section. Ajoutez le balisage suivant au fichier de Web.config votre application :
<configuration>
...
<system.web>
<customErrors mode="RemoteOnly"
defaultRedirect="~/ErrorPages/Oops.aspx" />
...
</system.web>
</configuration>
Le balisage ci-dessus configure l’application pour afficher les détails de l’exception YSOD aux utilisateurs qui visitent localement, tout en utilisant la page d’erreur personnalisée Oops.aspx pour les utilisateurs qui visitent à distance. Pour voir cela en action, déployez votre site web dans l’environnement de production, puis visitez la page Genre.aspx sur le site en direct avec une valeur de chaîne de requête non valide. Vous devriez voir la page d’erreur personnalisée (reportez-vous à la figure 3).
Pour vérifier que la page d’erreur personnalisée s’affiche uniquement aux utilisateurs distants, visitez la Genre.aspx page avec une chaîne de requête non valide à partir de l’environnement de développement. Vous devriez toujours voir les détails de l’exception YSOD (reportez-vous à la figure 1). Le RemoteOnly paramètre garantit que les utilisateurs qui visitent le site sur l’environnement de production voient la page d’erreur personnalisée tandis que les développeurs travaillant localement continuent à voir les détails de l’exception.
Notification aux développeurs et journalisation des détails de l’erreur
Les erreurs qui se produisent dans l’environnement de développement ont été provoquées par le développeur assis sur son ordinateur. Elle affiche les informations de l’exception dans le YSOD Détails de l’exception, et elle sait quelles étapes elle a effectuées lorsque l’erreur s’est produite. Mais lorsqu’une erreur se produit en production, le développeur n’a aucune connaissance qu’une erreur s’est produite, sauf si l’utilisateur final qui visite le site prend le temps de signaler l’erreur. Et même si l’utilisateur met tout en œuvre pour avertir l’équipe de développement qu’une erreur s’est produite, sans connaître le type d’exception, le message et la trace de pile, il peut être difficile de diagnostiquer la cause de l’erreur, et encore moins de la corriger.
Pour ces raisons, il est primordial que toute erreur dans l’environnement de production soit enregistrée dans un magasin persistant (par exemple, une base de données) et que les développeurs soient avertis de cette erreur. La page d’erreur personnalisée peut sembler être un bon endroit pour effectuer cette journalisation et cette notification. Malheureusement, la page d’erreur personnalisée n’a pas accès aux détails de l’erreur et ne peut donc pas être utilisée pour enregistrer ces informations. La bonne nouvelle est qu’il existe plusieurs façons d’intercepter les détails de l’erreur et de les journaliser, et les trois didacticiels suivants explorent cette rubrique plus en détail.
Utilisation de différentes pages d’erreur personnalisées pour différents états d’erreur HTTP
Lorsqu’une exception est levée par une page ASP.NET et n’est pas gérée, l’exception est percolée jusqu’au runtime ASP.NET, qui affiche la page d’erreur configurée. Si une demande arrive dans le moteur ASP.NET mais ne peut pas être traitée pour une raison quelconque (peut-être que le fichier demandé est introuvable ou que les autorisations de lecture ont été désactivées pour le fichier ), le moteur de ASP.NET déclenche un HttpException. Cette exception, comme les exceptions levées à partir de ASP.NET pages, s’affiche jusqu’au runtime, ce qui entraîne l’affichage de la page d’erreur appropriée.
Pour l’application web en production, cela signifie que si un utilisateur demande une page introuvable, la page d’erreur personnalisée s’affiche. La figure 6 montre un tel exemple. Étant donné que la demande concerne une page inexistante (NoSuchPage.aspx), une HttpException est levée et la page d’erreur personnalisée s’affiche (notez la référence à NoSuchPage.aspx dans le aspxerrorpath paramètre querystring).
Figure 6 : Le runtime ASP.NET affiche la page d’erreur configurée en réponse à une demande non valide
(Cliquez pour afficher l’image en taille réelle)
Par défaut, tous les types d’erreurs entraînent l’affichage de la même page d’erreur personnalisée. Toutefois, vous pouvez spécifier une page d’erreur personnalisée différente pour un code status HTTP spécifique à l’aide <error> d’éléments enfants dans la <customErrors> section. Par exemple, pour qu’une autre page d’erreur s’affiche en cas d’erreur de page introuvable, dont le code status HTTP est 404, mettez à jour la <customErrors> section pour inclure le balisage suivant :
<customErrors mode="RemoteOnly" defaultRedirect="~/ErrorPages/Oops.aspx">
<error statusCode="404" redirect="~/ErrorPages/404.aspx" />
</customErrors>
Une fois cette modification en place, chaque fois qu’un utilisateur qui visite à distance demande une ressource ASP.NET qui n’existe pas, il est redirigé vers la 404.aspx page d’erreur personnalisée au lieu de Oops.aspx. Comme l’illustre la figure 7 , la 404.aspx page peut inclure un message plus spécifique que la page d’erreur personnalisée générale.
Notes
Consultez Pages d’erreur 404, One More Time pour obtenir des conseils sur la création de pages d’erreur 404 effectives.
Figure 7 : La page d’erreur 404 personnalisée affiche un message plus ciblé que Oops.aspx
(Cliquez pour afficher l’image en taille réelle)
Étant donné que vous savez que la 404.aspx page n’est atteinte que lorsque l’utilisateur effectue une demande pour une page introuvable, vous pouvez améliorer cette page d’erreur personnalisée pour inclure des fonctionnalités permettant à l’utilisateur de résoudre ce type d’erreur spécifique. Par exemple, vous pouvez créer une table de base de données qui mappe les URL incorrectes connues à de bonnes URL, puis demander à la 404.aspx page d’erreur personnalisée d’exécuter une requête sur cette table et de suggérer des pages que l’utilisateur peut essayer d’atteindre.
Notes
La page d’erreur personnalisée s’affiche uniquement lorsqu’une demande est adressée à une ressource gérée par le moteur de ASP.NET. Comme nous l’avons vu dans le didacticiel Principales différences entre IIS et le serveur de développement ASP.NET , le serveur web peut gérer certaines requêtes lui-même. Par défaut, le serveur web IIS traite les demandes de contenu statique comme les images et les fichiers HTML sans appeler le moteur de ASP.NET. Par conséquent, si l’utilisateur demande un fichier image inexistant, il obtient le message d’erreur par défaut 404 d’IIS au lieu d’ASP. Page d’erreur configurée de NET.
Résumé
Lorsqu’une exception non gérée se produit dans une application ASP.NET, l’utilisateur affiche l’une des trois pages d’erreur suivantes : l’écran jaune détails de l’exception de la mort ; l’écran jaune d’erreur d’exécution de la mort ; ou une page d’erreur personnalisée. La page d’erreur qui s’affiche dépend de la configuration de <customErrors> l’application et de la visite locale ou à distance de l’utilisateur. Le comportement par défaut consiste à afficher les détails de l’exception YSOD aux visiteurs locaux et l’erreur d’exécution YSOD aux visiteurs distants.
Bien que l’erreur d’exécution YSOD masque les informations d’erreur potentiellement sensibles de l’utilisateur qui visite le site, elle s’interrompt par rapport à l’apparence de votre site et donne à votre application un aspect buggy. Une meilleure approche consiste à utiliser une page d’erreur personnalisée, ce qui implique de créer et de concevoir la page d’erreur personnalisée et de spécifier son URL dans l’attribut de defaultRedirect la <customErrors> section. Vous pouvez même avoir plusieurs pages d’erreur personnalisées pour différents états d’erreur HTTP.
La page d’erreur personnalisée est la première étape d’une stratégie complète de gestion des erreurs pour un site web en production. L’alerte du développeur de l’erreur et la journalisation de ses détails sont également des étapes importantes. Les trois didacticiels suivants explorent les techniques de notification et de journalisation des erreurs.
Bonne programmation!
En savoir plus
Pour plus d’informations sur les sujets abordés dans ce didacticiel, consultez les ressources suivantes :