Bonne pratique de traitement des erreurs

Question

Quelle est une bonne pratique de gestion des erreurs pour un site asp.net? Exemples? Merci!

Answer 1

Comme pour tout projet .net, le meilleur moyen consiste à ne capturer que des types d'erreur spécifiques s'ils risquent de se produire sur une page donnée.

Par exemple, vous pouvez intercepter les exceptions de format pour une entrée donnée par un utilisateur (si la validation JavaScript échoue et que vous n’avez pas utilisé la méthode tryparse), mais laissez toujours le contrôle de l’exception de niveau supérieur au gestionnaire d’erreur global.

     try
        {
            //Code that could error here
        }
        catch (FormatException ex)
        {
            //Code to tell user of their error
            //all other errors will be handled 
            //by the global error handler
        }

Vous pouvez utiliser les elmah (modules de journalisation et de gestion des erreurs) à code ouvert pour ASP. .Net pour faire cette erreur de niveau supérieur / global attraper pour vous si vous voulez.

En utilisant elmah , il est possible de créer un journal des erreurs qui est visible bien que simple. configurer l'interface web. Vous pouvez également filtrer différents types d’erreurs et avoir vos propres pages d’erreur pour différents types d’erreur.

Answer 2

Une pratique que je trouve particulièrement utile consiste à créer une page d'erreur générique, puis à définir votre defaultRedirect sur le nœud customErrors du web.config sur cette page d'erreur.

Configurez ensuite votre fichier global.asax pour la journalisation de toutes les exceptions non gérées, puis placez-les (exceptions non gérées) dans une propriété statique sur une classe (j'ai une classe appelée ErrorUtil avec une propriété LastError statique). Votre page d'erreur peut ensuite consulter cette propriété pour déterminer les éléments à afficher pour l'utilisateur.

Plus de détails ici: http://www.codeproject.com/KB/aspnet /JcGlobalErrorHandling.aspx

Answer 3

Eh bien, c'est assez grand ouvert, ce qui est complètement cool. Je vous renvoie à un mot .doc que vous pouvez télécharger à partir de Spider Net Net , qui est en fait la base de la norme de code de ma petite entreprise. La norme inclut des astuces très utiles pour la gestion des erreurs.

Un exemple de ce type pour les exceptions (je ne me souviens pas s'il s'agit du document original ou si nous l'avons ajouté au document): Ne faites jamais une «exception de capture et ne faites rien». Si vous masquez une exception, vous ne saurez jamais si cette exception s'est produite. Vous devriez toujours essayer d'éviter les exceptions en vérifiant toutes les conditions d'erreur par programmation.

Exemple de ce qu'il ne faut pas faire:

try
{
   ...
}
catch{}

Très méchant sauf si vous avez une bonne raison de le faire.

Answer 4

Assurez-vous de pouvoir détecter la plupart des erreurs générées par votre application et d'afficher un message convivial aux utilisateurs. Mais bien sûr, vous ne pouvez pas capturer toutes les erreurs car vous pouvez utiliser web.config et defaultRedirect par un autre utilisateur. ELMAH est un autre outil très utile pour consigner les erreurs. ELMAH enregistrera toutes les erreurs générées par votre application et vous les montrera de manière très lisible. Brancher ELMAH dans votre application est aussi simple que d'ajouter quelques lignes de code dans le fichier web.config et de connecter l'assembly. Vous devriez absolument essayer ELMAH, il vous épargnera des heures et des heures de douleur.

http://code.google.com/p/elmah/

Answer 5

1. Codez de manière défensive dans chaque page les exceptions susceptibles de survenir et gérez-les correctement, afin de ne pas perturber l'utilisateur à chaque fois qu'une exception se produit.

2. Enregistrez toutes les exceptions, avec une référence.

3. Fournissez une page d'erreur générique, pour toute exception non gérée, fournissant une référence à utiliser pour le support (le support peut identifier les détails à partir des journaux). N'affichez pas l'exception réelle, car la plupart des utilisateurs ne la comprendront pas, mais constitue un risque potentiel pour la sécurité car elle expose des informations sur votre système (potentiellement des mots de passe, etc.).

4. Ne capturez pas toutes les exceptions et ne faites rien avec elles (comme dans la réponse ci-dessus). Il n’ya presque jamais de bonne raison de le faire. Parfois, vous voudrez peut-être capturer une exception spécifique et ne pas en faire délibérément, mais cela doit être utilisé à bon escient.

Answer 6

Il n’est pas toujours judicieux de rediriger l’utilisateur vers une page d’erreur standard. Si un utilisateur travaille sur un formulaire, il se peut qu'il ne souhaite pas être redirigé hors du formulaire sur lequel il travaille. Je mets tout le code qui pourrait causer une exception dans un bloc try / catch et à l'intérieur du bloc catch, je crache un message d'alerte alertant l'utilisateur qu'une erreur s'est produite ainsi que de consigner l'exception dans une base de données, y compris la saisie de formulaire, la chaîne de requête , etc. Je développe un site interne, cependant, donc la plupart des utilisateurs ne m'appellent que s'ils rencontrent un problème. Pour un site public, vous pouvez utiliser quelque chose comme elmah.

Answer 7

public string BookLesson(Customer_Info oCustomerInfo, CustLessonBook_Info oCustLessonBookInfo)
    {
        string authenticationID = string.Empty;
        int customerID = 0;
        string message = string.Empty;
        DA_Customer oDACustomer = new DA_Customer();

        using (TransactionScope scope = new TransactionScope())
        {
            if (oDACustomer.ValidateCustomerLoginName(oCustomerInfo.CustId, oCustomerInfo.CustLoginName) == "Y")
            {
                // if a new student
                if (oCustomerInfo.CustId == 0)
                {
                    oCustomerInfo.CustPassword = General.GeneratePassword(6, 8);
                    oCustomerInfo.CustPassword = new DA_InternalUser().GetPassword(oCustomerInfo.CustPassword, false);
                    authenticationID = oDACustomer.Register(oCustomerInfo, ref customerID);
                    oCustLessonBookInfo.CustId = customerID;
                }
                else // if existing student
                {
                    oCustomerInfo.UpdatedByCustomer = "Y";
                    authenticationID = oDACustomer.CustomerUpdateProfile(oCustomerInfo);
                }
                message = authenticationID;
                // insert lesson booking details
                new DA_Lesson().BookLesson(oCustLessonBookInfo);
            }

            else
            {
                message = "login exists";
            }
            scope.Complete();
            return message;
        }

    }