Gestion des exceptions

La classe Exception

Toute application, même testée et déboguée, peut rencontrer des erreurs d’exécution. Par exemple, si l’application a besoin d’une ressource sur un réseau et qu’elle n’est pas disponible, l’erreur doit être interceptée et traitée. Les erreurs ne sont pas seulement dues au code de l’application. Il faut également prendre en considération l’environnement d’exécution pour gérer correctement les erreurs.

Le Framework .NET fournit toute une hiérarchie de classes représentant les différents types d’erreurs pouvant survenir. Toutes ces classes dérivent à un niveau plus ou moins lointain de la classe de base Exception qui contient des informations sur l’erreur qui a été levée comme le message, la source, la trace, l’erreur d’origine. La classe Exception étant très générale, vous ne souhaiterez pas lever des erreurs de ce type. Deux classes en dérivent permettant de séparer les types d’erreurs :

La création d’exceptions personnalisées

Les types d’exceptions fournis par le Framework .NET ne correspondent pas forcément au besoin d’une application qui nécessiterait un type d’exception contenant des champs spécifiques. La création d’exceptions personnalisées se fait en créant un nouveau type héritant de la classe System.ApplicationException.

public class ProjectException : ApplicationException 
{ 
    public Project Project { get; protected set; } 
 
    public ProjectException(Project project) 
        : base() 
    { 
        this.Project = project; 
    } 
    public ProjectException(Project project, string message) 
        : base(message) 
    { 
        this.Project = project; 
} 
    public...

Le déclenchement des exceptions

En règle générale, une exception est déclenchée par le système mais vous pouvez avoir besoin de déclencher une exception plus spécifique ou plus détaillée pour la traiter plus haut dans la pile des appels.

Observez l’accesseur set de la propriété SendDelay de la classe ProjectSettings :

public int SendDelay 
{ 
    get { return this.sendDelay; } 
    set 
    { 
        if (value < 0) 
            throw new ArgumentException("La valeur doit être  
supérieure ou égale à 0.", "Délai d'envoi"); 
        if (this.sendDelay != value) 
        { 
            this.sendDelay = value; 
            this.HasChanged = true; 
        } 
    } 
} 

Lors de l’affectation d’une valeur, celle-ci est testée afin de déterminer si elle est supérieure...

L’interception et la gestion des exceptions

Les exceptions font partie intégrante du cycle de vie d’une application. Si elles ne peuvent pas toujours être évitées, il est par contre indispensable de les intercepter et de les gérer d’une manière n’empêchant pas la suite de l’exécution de l’application. Le bloc try ... catch ... finally permet d’une part d’intercepter les erreurs et d’autre part de les traiter :

try 
{ 
    Instructions. 
} 
catch 
{ 
    Instructions de gestion d'une erreur. 
} 
finally 
{ 
    Instructions toujours exécutées. 
} 

La partie try contient les instructions qui peuvent déclencher une erreur. Si une exception est déclenchée directement via une instruction throw ou depuis la pile des appels, l’exécution passe immédiatement dans la partie catch afin de traiter l’erreur. Qu’une exception soit levée ou non, la partie finally est toujours exécutée.

Les blocs finally contiennent les instructions qui seront exécutées en toutes circonstances. C’est dans ce bloc que les ressources doivent être libérées ou que les données doivent être enregistrées. 

Lorsqu’une exception est déclenchée, une référence à l’objet Exception est disponible et peut être captée au niveau de la partie catch :

try 
{ 
    Project = new Library.Project(); 
    Project.ProjectSettings.SendDelay = -1; 
} 
catch (Exception ex) 
{ 
    MessageBox.Show(ex.Message); 
} 

Toutes les exceptions dérivant de System.Exception, le bloc catch de l’exemple précédent traitera toutes les erreurs. Il est possible de spécifier un type plus précis afin de gérer l’erreur d’une manière différente :

catch (ArgumentException ex) 
{ 
    MessageBox.Show(ex.Message); 
    Project.ProjectSettings.SendDelay = 0; 
} 

Un gestionnaire d’erreurs peut contenir...