Gestion de l'exception

Dernière mise à jour le par BunoCS .

Gestion de l'exception

Introduction

Un gestionnaire d'exception établit un ensemble de routines de traitement d'erreurs, définies par le programmeur, sur un bloc (dans une fonction ou une méthode du programme) ; ces routines sont activées pendant toute la durée d'exécution du bloc protégé.

L'Exception

La première chose que je regarde lors de l'évaluation du code de quelqu'un est un bloc try / catch. Même s'il n'est pas un indicateur parfait, la gestion des exceptions est l'une des rares choses qui parlent vite sur la qualité du code. En quelques secondes, vous pourriez découvrir que l'auteur code n'a pas la moindre idée de ce qu'il ou elle fait. La gestion des exceptions pauvres peuvent avoir un impact sérieux sur la maintenance d'un système. Une bonne gestion des exceptions n'est pas très difficile. Techniquement il n'y a rien à elle. Le tout se résume à saisir les fondements. Trop nombreux sont les développeurs qui envisagent les exceptions comme dangereuses pour le système.

Traiter les Exception

Il y a 3 façons de traiter les exceptions en ASP.Net

Niveau Méthode (Fonction)

public void DownloadPdf(string path)
{
    try
    {
        System.IO.StreamReader reader = System.IO.File.OpenText(path);
    }
    catch (System.UnauthorizedAccessException ex)
    {
        //Hey, vous n'avez pas accès à la file!
    }
    catch (System.IO.FileNotFoundException ex)
    {
        // Eh oui, le fichier n'existe pas
    }
    catch (Exception ex)
    {
        // Oh La..la...
    }
}

Niveau Page

protected override void OnError(EventArgs e)
{
    Exception exception = HttpContext.Current.Server.GetLastError();
    // Informer l'utilisateur sur l'exception, l'enregistrer dans le log..etc..
}

Niveau Application

// In global.asax
protected void Application_Error(object sender, EventArgs e)
{
    Exception ex = HttpContext.Current.Server.GetLastError();

    // Faites ce que vous devez par rapport à l'exception
}

Quelques règles de base

Ne jetez pas new Exception ()
Exception est une classe trop large, et il est difficile de l'attraper sans effets secondaires. Dériver votre propre classe d'exception, à partir de ApplicationException. De cette manière vous pouvez définir un gestionnaire d'exception spécialisé pour les exceptions levées par le « framework » et l'autre pour les exceptions levées par vous-même.

Ne mettez pas d'information importante sur le champ Message
Les exceptions sont des classes. Lorsque vous retournez les informations exception, créer des champs pour stocker des données. Si vous ne parvenez pas à faire ça, les gens vont avoir à analyser le champ Message d'obtenir l'information dont ils ont besoin. Maintenant, imaginez ce qui se passera dans le code appelant si vous avez besoin de localiser ou même à corriger juste une faute d'orthographe dans les messages d'erreur...

Mettre « single catch » (Exception ex) par thread
La gestion des exceptions génériques devraient se faire en un point central dans votre application. Chaque thread a besoin d'un bloc try / catch, ou vous perdrez des exceptions et vous aurez des problèmes difficiles à comprendre. Quand une application se lance et que plusieurs threads font du traitement en background, souvent vous créez une classe pour le stockage des résultats du traitement. N'oubliez pas d'ajouter un champ pour le stockage d'une exception qui pourrait arriver ou vous ne serez pas en mesure de le communiquer au thread principal.

Exceptions génériques capturés devraient être publiés
Il n'a vraiment pas d'importance ce que vous utilisez pour les logs - log4net, FEI, Event Log, TraceListeners, les fichiers texte, etc Ce qui est vraiment important, c'est: si vous avez attrapé une exception générique. Mais ce journal qu'une seule fois - souvent code est monté avec des blocs catch qui exceptions journal et vous vous retrouvez avec un journal grand, avec trop d'informations répétées d'être utile.

Ne catcher pas le même type d'exceptions plusieurs fois par thread
Il existe de rares exceptions près (sans jeu de mots) à cette règle. Si vous avez besoin pour intercepter une exception, utilisez toujours l'exception la plus spécifique pour le code que vous écrivez.
Je vois toujours les débutants penser qu'un bon code est un code qui ne lève pas d'exceptions. Ce n'est pas vrai. Un bon code envoie des exceptions au besoin, et ne gère que les exceptions qu'il sait traiter.

Conclusion

Vous ne devriez lancer des exceptions que quand une condition est en dehors des hypothèses de votre code. En d'autres termes, n'utilisez pas des exceptions comme un moyen de fournir la fonctionnalité de votre intention, même si quelque chose s'est mal passé.

Toutefois, une exception doit être générée si un véritable état de légitime inattendu se produit, comme une base de données utilisateur indisponible. Lancer ou permettre la possibilité de lancer des exceptions est plus cher que de simplement revenir suite à un appelant ou d'avoir le code pour gérer une condition attendue. Par conséquent, les exceptions ne devraient pas être utilisées pour contrôler le flux normal de l'exécution par le biais de votre code.

Ce document intitulé « Gestion de l'exception » issu de CodeS SourceS (codes-sources.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.
Introduction à la plateforme .Net et ASP.Net
Calendrier des événements pour ASP.Net MVC - Tutoriel vidéo
Rejoignez-nous