Affichage d’une page d’erreur personnalisée (C#)

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 de 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 écrivaient 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 seraient jamais hors connexion. Bien sûr, en réalité, les erreurs sont inévitables. Les classes du .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 de 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 d’un try bloc lève une exception, le contrôle est transféré vers le bloc de capture approprié où le développeur peut tenter de récupérer après 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 d’essai, l’exception percole la pile des appels dans la recherche de try/catch/finally blocs.

Si l’exception bulle jusqu’au 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 qui déboguent l’application (voir figure 1) ; l’autre indique simplement qu’il y a eu une erreur d’exécution (voir figure 2).

Les détails de l’exception YSOD sont très utiles pour les développeurs qui déboguent l’application, mais l’affichage d’un YSOD aux utilisateurs finaux est peu 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 se produit dans une application ASP.NET l’un des trois types de pages d’erreur s’affiche :

• Page d’erreur De l’écran jaune des détails de l’exception de la mort,
• La page d’erreur d’erreur d’exécution de la mort, 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 le code dans la classe code-behind de votre page 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 au-dessous de celle-ci).

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 (un uniqueidentifier) soit transmise via la chaîne de requête ; par exemple, l’URL appropriée pour afficher les révisions de fiction est Genre.aspx?ID=7683ab5d-4589-4f03-a139-1c26044d0146. Si uneuniqueidentifier autre valeur est transmise via la chaîne de requête (par exemple, « foo »), une exception est levée.

Notez les informations d’exception 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 existe é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é à 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 levée. (Toutefois, il fournit des instructions sur la façon de rendre les détails de l’erreur visibles en modifiant le Web.config fichier, ce qui fait partie de ce qui rend une telle YSOD non professionnelle.)

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 sont intéressés à connaître les détails de l’erreur, mais ces informations ne doivent pas être affichées sur un site en direct, car elles peuvent révéler des vulnérabilités de sécurité potentielles ou d’autres informations sensibles à quiconque visite votre site.

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 avez 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 prise en charge. 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 s’affichent 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

Laquelle des trois pages d’erreur possibles s’affiche est basée sur deux variables :

• Les informations de configuration de la <customErrors> section, et
• Indique si l’utilisateur visite le site localement ou à distance.

La <customErrors> section dans 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 : 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 les détails de l’exception YSOD s’affichent à 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 les détails de l’exception YSOD s’affichent 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 les détails de l’exception YSOD s’affichent aux visiteurs locaux, tandis que le YSOD d’erreur d’exécution s’affiche 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 ajouté à ce nouveau ASP.NET page nommé Oops.aspx. Faites en sorte que la page utilise la même master page 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.

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.

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 :

• Pages d’erreur, une fois de plus
• Instructions de conception pour les exceptions
• Pages d’erreur conviviales
• Gestion et levée des exceptions
• Utilisation correcte des pages d’erreur personnalisées dans ASP.NET
• Vue d'ensemble du traçage ASP.NET