Vue d'ensemble des exceptions
Mise à jour : novembre 2007
Une exception est un cas d'erreur ou un comportement inattendu qui se produit pendant l'exécution d'un programme. Des exceptions peuvent être levées à cause d'une erreur dans votre code ou dans le code que vous appelez (une bibliothèque partagée, par exemple), de ressources du système d'exploitation non disponibles, de conditions inattendues rencontrées par le Common Language Runtime (un code qui ne peut pas être vérifié, par exemple), etc. Votre application peut récupérer à partir de certaines de ces erreurs, mais pas d'autres. S'il est possible de récupérer à partir de la plupart des exceptions générées par l'application ; il est impossible de récupérer à partir de la plupart des exceptions runtime.
Dans le .NET Framework, une exception est un objet qui hérite de la classe Exception. Une exception est levée à partir d'une partie du code où un problème s'est produit. L'exception remonte la pile qu'à sa prise en charge par l'application ou l'arrêt du programme. Pour plus d'informations sur la gestion des exceptions à l'aide du .NET Framework, consultez la rubrique Exception, classe.
Gestion des exceptions par le runtime
Le runtime utilise un modèle de gestion des exceptions fondé sur des objets exception et des blocs de code protégés. Un objet Exception est créé pour représenter une exception lorsque celle-ci est levée.
Le runtime crée une table d'informations sur les exceptions pour chaque exécutable. Chaque méthode de l'exécutable a un tableau associé d'informations de gestion des exceptions (qui peut être vide) contenu dans la table d'informations sur les exceptions. Chaque entrée du tableau décrit un bloc de code protégé, d'éventuels filtres d'exceptions associés à ce code et d'éventuels gestionnaires d'exceptions (instructions catch). Cette table d'exceptions est extrêmement efficace et aucune dégradation des performances n'est constatée, que ce soit au niveau du temps du processeur ou de l'utilisation de la mémoire, lorsqu'une exception ne se produit pas. Les ressources sont utilisées uniquement lorsqu'une exception se produit.
La table d'informations sur les exceptions représente quatre types de gestionnaires d'exceptions pour les blocs protégés :
Un gestionnaire finally qui s'exécute à chaque sortie du bloc, que cette situation soit le résultat d'un flux de contrôle normal ou d'une exception non gérée.
Un gestionnaire de pannes qui doit s'exécuter lorsqu'une exception se produit, mais ne s'exécute pas à l'issue de l'achèvement du flux de contrôle normal.
Un gestionnaire filtré par type qui gère toute exception d'une classe spécifiée ou l'une de ses classes dérivées.
Un gestionnaire filtré par l'utilisateur qui exécute un code spécifié par l'utilisateur afin de déterminer si l'exception doit être gérée par le gestionnaire associé ou passée au bloc protégé suivant.
Chaque langage implémente ces gestionnaires d'exceptions selon ses propres spécifications. Par exemple, Visual Basic 2005 donne accès à un gestionnaire filtré par l'utilisateur via une comparaison de variables (à l'aide du mot clé When) dans l'instruction catch ; C# n'implémente pas le gestionnaire filtré par l'utilisateur.
Lorsqu'une exception se produit, le runtime déclenche un processus en deux étapes :
Le runtime recherche dans le tableau le premier bloc protégé qui :
protège une partie contenant l'instruction en cours d'exécution, et
contient un gestionnaire d'exceptions ou un filtre chargé de la gestion de l'exception.
En cas de concordance, le runtime crée un objet Exception qui décrit l'exception. Le runtime exécute ensuite toutes les instructions finally ou fault situées entre l'instruction où l'exception s'est produite et l'instruction qui gère l'exception. Notez que l'ordre des gestionnaires d'exceptions est important : le gestionnaire d'exceptions le plus profond est évalué en premier. Notez également que les gestionnaires d'exceptions peuvent accéder aux variables locales et à la mémoire locale de la routine qui intercepte l'exception, mais les éventuelles valeurs intermédiaires survenant au moment où l'exception est levée sont perdues.
Si aucune correspondance n'est trouvée dans la méthode en cours, le runtime explore chaque appelant de la méthode en cours, puis poursuit ce chemin en remontant la pile. Si aucun appelant n'a de correspondance, le runtime autorise le débogueur à accéder à l'exception. Si le débogueur ne s'attache pas à l'exception, le runtime déclenche l'événement UnhandledException. Si aucun écouteur n'existe pour l'événement UnhandledException, le runtime fait un dump d'une trace de la pile et arrête le programme.
Filtrage des exceptions runtime
Vous pouvez filtrer les exceptions que vous interceptez et gérez soit par type soit par des critères définis par l'utilisateur.
Les gestionnaires filtrés par type gèrent un type particulier d'exception (ou de classes qui en sont dérivées). La forme la plus commune du gestionnaire d'exceptions filtré par type spécifie que seule une classe particulière d'exceptions peut être interceptée.
L'exemple suivant illustre un gestionnaire d'exceptions conçu pour intercepter une exception spécifique, en l'occurrence FileNotFoundException.
Catch e As FileNotFoundException
Console.WriteLine("[Data File Missing] {0}", e)
catch(FileNotFoundException e) {
Console.WriteLine("[Data File Missing] {0}", e);
}
Les gestionnaires d'exceptions filtrés par l'utilisateur interceptent et gèrent les exceptions selon des critères que vous définissez pour l'exception. Ces gestionnaires utilisent l'instruction Catch avec le mot clé When dans Visual Basic 2005. Pour plus d'informations sur ce mode de filtrage des exceptions, consultez Utilisation d'exceptions spécifiques dans un bloc catch.
Voir aussi
Concepts
Classe et propriétés d'exception
Méthodes conseillées pour la gestion des exceptions