Examiner les exceptions et le processus de gestion des exceptions

11 minutes

Les erreurs d’exécution dans une application C# sont gérées à l’aide d’un mécanisme appelé exceptions. Les exceptions fournissent un moyen structuré, uniforme et sécurisé de gérer les conditions d’erreur au niveau du système et au niveau de l’application. Les exceptions sont générées par le runtime .NET ou par le code d’une application.

Scénarios courants nécessitant une gestion des exceptions

Il existe plusieurs scénarios de programmation qui nécessitent une gestion des exceptions. La plupart de ces scénarios impliquent une forme d’acquisition de données. Bien que certains scénarios impliquent des techniques de codage qui ne sont pas dans le cadre de cette formation, elles valent toujours la peine de noter.

Les scénarios courants qui nécessitent une gestion des exceptions sont les suivants :

Entrée utilisateur : des exceptions peuvent se produire lorsque le code traite l’entrée utilisateur. Par exemple, des exceptions se produisent lorsque la valeur d’entrée est au format incorrect ou hors plage.
Traitement des données et calculs : des exceptions peuvent se produire lorsque le code effectue des calculs ou des conversions de données. Par exemple, des exceptions se produisent lorsque le code tente de diviser par zéro, de convertir en type non pris en charge ou d’affecter une valeur hors plage.
Opérations d’entrée/sortie de fichier : des exceptions peuvent se produire lorsque le code lit ou écrit dans un fichier. Par exemple, des exceptions se produisent lorsque le fichier n’existe pas, que le programme n’a pas l’autorisation d’accéder au fichier ou que le fichier est utilisé par un autre processus.
Opérations de base de données : des exceptions peuvent se produire lorsque le code interagit avec une base de données. Par exemple, des exceptions se produisent lorsque la connexion de base de données est perdue, qu’une erreur de syntaxe se produit dans une instruction SQL ou qu’une violation de contrainte se produit.
Communication réseau : les exceptions peuvent se produire lorsque le code communique sur un réseau. Par exemple, des exceptions se produisent lorsque la connexion réseau est perdue, qu’un délai d’expiration se produit ou que le serveur distant retourne une erreur.
Autres ressources externes : des exceptions peuvent se produire lorsque le code communique avec d’autres ressources externes. Les services web, les API REST ou les bibliothèques tierces peuvent lever des exceptions pour différentes raisons. Par exemple, des exceptions se produisent en raison de problèmes de connexion réseau, de données incorrectes, etc.

Mots clés de gestion des exceptions, blocs de code et modèles

La gestion des exceptions en C# est implémentée à l’aide des mots clés try, catch, et finally. Chacun de ces mots clés a un bloc de code associé et peut être utilisé pour satisfaire un objectif spécifique dans votre approche de la gestion des exceptions. Par exemple:

try
{   
   // try code block - code that may generate an exception
}
catch
{   
   // catch code block - code to handle an exception
}
finally
{   
   // finally code block - code to clean up resources
}

Remarque

Le langage C# permet également à votre code de générer un objet d’exception à l’aide du throw mot clé. Les scénarios de gestion des exceptions qui incluent l’utilisation du throw mot clé pour générer des exceptions sont couverts dans un module distinct sur Microsoft Learn.

Le bloc de code try contient le code protégé susceptible de provoquer une exception. Si le code dans un try bloc provoque une exception, l’exception est gérée par un bloc correspondant catch .

Le bloc de code catch contient le code qui est exécuté lorsqu’une exception est interceptée. Le catch bloc peut gérer l’exception, la consigner ou l’ignorer. Un catch bloc peut être configuré pour s’exécuter lorsqu’un type d’exception se produit ou uniquement lorsqu’un type spécifique d’exception se produit.

Le finally bloc de code contient du code qui s’exécute si une exception se produit ou non. Le finally bloc est souvent utilisé pour nettoyer les ressources allouées dans un try bloc. Par exemple, s’assurer qu’une variable a la valeur correcte ou requise qui lui est affectée.

La gestion des exceptions dans une application C# est généralement implémentée à l’aide d’un ou plusieurs des modèles suivants :

Le try-catch modèle se compose d’un try bloc suivi d’une ou plusieurs catch clauses. Chaque catch bloc est utilisé pour spécifier des gestionnaires pour différentes exceptions.
Le try-finally modèle se compose d’un try bloc suivi d’un finally bloc. En règle générale, les instructions d’un finally bloc s’exécutent lorsque le contrôle quitte une try instruction.
Le try-catch-finally modèle implémente les trois types de blocs de gestion des exceptions. Un scénario courant pour le try-catch-finally modèle est le moment où les ressources sont obtenues et utilisées dans un try bloc, des circonstances exceptionnelles sont gérées dans un catch bloc, et les ressources sont libérées ou gérées dans le finally bloc.

Comment les exceptions sont-elles représentées dans le code ?

Les exceptions sont représentées dans le code en tant qu’objets, ce qui signifie qu’elles sont une instance d’une classe. La bibliothèque de classes .NET fournit des classes d’exception accessibles dans le code comme d’autres classes .NET. Un autre exemple de classe .NET utilisée comme objet dans le code est la Random classe (utilisée pour créer des nombres aléatoires).

Plus précisément, les exceptions sont des types, représentés par des classes qui sont toutes dérivées de System.Exception. Une classe d’exception dérivée d’informations Exception inclut des informations qui identifient le type d’exception et contiennent des propriétés qui fournissent des détails sur l’exception. Un examen plus détaillé de la Exception classe est inclus plus loin dans ce module.

Une instance runtime d’une classe est généralement appelée objet. Par conséquent, les exceptions sont souvent appelées objets d’exception.

Remarque

Bien qu’ils soient parfois utilisés de façon interchangeable, une classe et un objet sont différents. Une classe définit un type d’objet, mais ce n’est pas un objet lui-même. Un objet est une entité concrète basée sur une classe.

Processus de gestion des exceptions

Lorsqu’une exception se produit, le runtime .NET recherche la clause la plus catch proche qui peut gérer l’exception. Le processus commence par la méthode qui a provoqué la levée de l’exception. Tout d’abord, la méthode est examinée pour voir si le code qui a provoqué l’exception se trouve à l’intérieur d’un try bloc de code. Si le code se trouve à l’intérieur du bloc de code try, les clauses catch associées à l’instruction try sont considérées dans l’ordre. Si les catch clauses ne peuvent pas gérer l’exception, la méthode appelée méthode actuelle est recherchée. Cette méthode est examinée pour déterminer si l’appel de méthode (à la première méthode) se trouve à l’intérieur d’un try bloc de code. Si l’appel se trouve à l’intérieur d’un try bloc de code, les clauses associées catch sont prises en compte. Ce processus de recherche se poursuit jusqu’à ce qu’une catch clause soit trouvée qui peut gérer l’exception actuelle.

Une fois qu’une catch clause est trouvée qui peut gérer l’exception, le runtime se prépare à transférer le contrôle vers la première instruction du catch bloc. Toutefois, avant le début de l’exécution du catch bloc, le runtime exécute tous les finally blocs associés aux try instructions trouvées pendant la recherche. Si plusieurs finally blocs sont trouvés, ils sont exécutés dans l’ordre, en commençant par celui le plus proche du code qui a provoqué la levée de l’exception.

Si aucune clause n’est catch trouvée pour gérer l’exception, le runtime met fin à l’application et affiche un message d’erreur à l’utilisateur.

Considérez l’exemple de code suivant qui inclut un try-finally modèle imbriqué à l’intérieur d’un try-catch modèle :

try
{
    // Step 1: code execution begins
    try
    {
        // Step 2: an exception occurs here
    }
    finally
    {
        // Step 4: the system executes the finally code block associated with the try statement where the exception occurred
    }

}
catch // Step 3: the system finds a catch clause that can handle the exception
{   
   // Step 5: the system transfers control to the first line of the catch code block
}

Dans cet exemple, le processus suivant se produit :

L’exécution commence dans le bloc de code de l’instruction externe try .
Une exception est levée dans le bloc de code de l’instruction interne try.
Le runtime recherche la catch clause associée à l’instruction externe try .
Avant que le système d'exécution transfère le contrôle à la première ligne du bloc de code catch, il exécute la clause finally associée à l'instruction interne try.
Le runtime transfère ensuite le contrôle à la première ligne du bloc de catch code et exécute le code qui gère l’exception.

Dans cet exemple simple, les modèles imbriqués try-catch et try-finally résident tous dans une seule méthode, mais plusieurs modèles try-catch et try-finally peuvent être répartis entre les différentes méthodes qui appellent d’autres méthodes.

Gestion des exceptions et pile des appels

Vous verrez souvent le terme « déroulement de la pile des appels » lorsque vous découvrez la gestion des exceptions et le processus de gestion des exceptions. Pour comprendre ce terme, vous devez comprendre la pile des appels et comment elle est utilisée pour suivre la « pile » des appels de méthode pendant l’exécution du code.

Vous pouvez considérer la pile des appels comme une tour de blocs. Lorsque vous construisez une tour, vous commencez par un seul bloc. Chaque fois que vous ajoutez un bloc à la tour, vous le placez sur les blocs existants. Lorsque votre application commence à s’exécuter dans le débogueur, le point d’entrée vers votre application est la première couche ajoutée à la pile des appels (le premier bloc de la tour). Chaque fois qu’une méthode appelle une autre méthode, la nouvelle méthode est ajoutée au début de la pile. Lorsque votre code quitte une méthode, la méthode est supprimée de la pile des appels.

Remarque

Pour une application console, le point d’entrée vers votre application est les instructions de niveau supérieur. Dans la pile d'appels de Visual Studio Code, ce point d'entrée est appelé la méthode Main.

Le déroulement de la pile des appels est le processus utilisé par le runtime .NET lorsqu’un programme C# rencontre une erreur. C’est le même processus que celui que vous venez de passer en revue.

Revenez à l’analogie de la tour de bloc, lorsque vous devez supprimer un bloc de la tour, vous commencez par le haut et supprimez chaque bloc jusqu’à atteindre celui dont vous avez besoin. Ce processus est similaire au fonctionnement du déroulement de la pile des appels, où chaque couche d’appels de la pile est comme un bloc dans la tour. Lorsque le runtime doit décompresser la pile des appels, il commence à partir du haut et supprime chaque couche d’appels jusqu’à ce qu’il atteigne celui dont il a besoin. Dans ce cas, la couche d’appels nécessaire est la méthode qui a une clause catch qui peut gérer l’exception qui s’est produite.

Récapitulatif

Voici quelques points importants à retenir de cette unité :

Les scénarios courants qui peuvent nécessiter la gestion des exceptions incluent l’entrée utilisateur, le traitement des données, les opérations d’E/S de fichier, les opérations de base de données et la communication réseau.
La gestion des exceptions en C# est implémentée à l’aide des mots clés try, catch et finally. Chaque mot clé a un bloc de code associé qui sert un objectif spécifique.
Les exceptions sont représentées en tant que types et dérivées de la System.Exception classe dans .NET. Les exceptions contiennent des informations qui identifient le type d’exception et les propriétés qui fournissent des détails supplémentaires.
Lorsqu’une exception se produit, le runtime .NET recherche la clause la plus catch proche qui peut la gérer. La recherche commence par la méthode où l’exception a été levée et se déplace vers le bas de la pile d’appels si nécessaire.

Commentaires

Cette page a-t-elle été utile ?

Examiner les exceptions et le processus de gestion des exceptions

Vérifier vos connaissances

Commentaires