Les différents types d’erreurs

Aucun logiciel n’est exempt de bugs, et aucun développeur n’écrit de code sans faire la moindre faute de frappe ou oublier le moindre point-virgule. Malgré toute l’attention que les développeurs portent à leur ouvrage, ces erreurs sont inévitables. Il est donc nécessaire de pouvoir les identifier et les corriger.

1. Erreurs de compilation

Les erreurs de compilation sont des erreurs empêchant la génération d’un assembly à partir du code. Ces erreurs sont souvent des erreurs de syntaxe, mais elles peuvent aussi être liées à la mauvaise utilisation d’un objet, d’une méthode ou de tout autre élément de code.

Ces erreurs sont détectées durant la compilation, évidemment, mais aussi durant l’écriture du programme. En effet, Visual Studio analyse le code en permanence de manière à fournir un maximum d’informations le plus tôt possible, ce qui diminue la difficulté et le coût de la correction de chacune des erreurs.

Affichage dans la fenêtre d’édition

Les erreurs détectées par l’analyse permanente sont affichées directement dans la fenêtre d’édition. Les portions de code générant des erreurs sont marquées par un soulignement...

Utilisation des exceptions

Le déclenchement d’une exception permet d’interrompre le flux normal d’exécution de l’application tout en fournissant des informations sur l’erreur qu’elle représente. Sans intervention du développeur pour la gérer, elle se propage automatiquement en remontant la pile des appels jusqu’au point d’entrée de l’application où elle peut causer sa fermeture complète.

1. Création et déclenchement d’exceptions

Les exceptions sont représentées par des objets héritant de la classe System.Exception. Elles peuvent être générées (levées) à tout endroit de l’application.

a. La classe Exception

La classe System.Exception est la classe de base de toutes les exceptions. Ses membres lui permettent de contenir de nombreuses informations relatives à l’erreur en cours de propagation. La plupart de ces membres sont valorisés automatiquement lorsqu’une exception est levée. Parmi ceux-ci, on trouve notamment la propriété StackTrace qui contient des informations particulièrement intéressantes pour localiser la source de l’exception.

L’instanciation d’un objet de type Exception peut être faite à l’aide de trois constructeurs :

public Exception(); 

public Exception(string message); 

public Exception(string message, Exception innerException);

Le paramètre message correspond à un libellé personnalisé permettant de comprendre l’erreur lorsqu’elle est traitée loin de sa source. On peut par la suite retrouver ce libellé en consultant la propriété Message de l’exception.

Le paramètre innerException permet quant à lui d’encapsuler une exception que l’on traite dans une nouvelle exception que l’on génère.

b. Le mot-clé throw

Instancier un objet de type Exception ne suffit pas à lever l’exception. Pour ce faire, il est nécessaire d’exécuter une instruction throw en fournissant l’objet Exception à lever.

public void CompterJusqua(int nombre) 
{ 
    if (nombre < 0) 
    { 
       string message = string.Format("Impossible...

Les outils fournis par Visual Studio

Les causes des erreurs de logique peuvent être particulièrement délicates à déceler. Visual Studio fournit pour cela un certain nombre d’outils permettant de contrôler l’état d’exécution de l’application, de placer des points d’arrêt ou de visualiser les données manipulées par l’application.

1. Contrôle de l’exécution

Pour pouvoir explorer le code à la recherche de la cause d’une erreur d’exécution ou de logique, il est important de pouvoir contrôler l’exécution d’une application dans des conditions permettant cette exploration. Visual Studio intègre cette possibilité au travers de l’utilisation d’un débogueur.

Dans Visual Studio, un projet peut se trouver dans trois états distincts :

En mode conception : le développement est en cours.
En exécution : le code est compilé et l’application est lancée et attachée au débogueur intégré.
En pause : le débogueur a stoppé l’exécution de l’application entre deux instructions.

a. Démarrage

Le lancement de l’application en mode débogage (Debug dans Visual Studio) est effectué en cliquant sur le bouton Démarrer de la barre d’outils.

Il est aussi possible de lancer le débogage en utilisant la touche [F5] du clavier.

La combinaison de touches [Ctrl][F5] lance l’application normalement, sans l’attacher au débogueur de Visual Studio. Le projet reste en mode conception, mais il est impossible de le compiler ou le lancer tant que l’application n’a pas été fermée.

Lorsque la solution contient plusieurs projets, le projet généré et lancé est celui qui a été défini comme projet de démarrage. Il est aussi nécessaire que ce projet génère un fichier exécutable. Dans le cas contraire, une erreur est affichée.

b. Arrêt

Lorsque le projet est en mode exécution ou pause, il est possible d’arrêter complètement son exécution afin de repasser en mode conception. Cette action est effectuée par un clic sur le bouton d’arrêt qui apparaît...

L’erreur à un milliard de dollars : les références nulles

Nous avons abordé l’existence des références nulles au chapitre Les bases du langage (section Types valeurs et types références). Pour rappel, elles correspondent à l’état d’une variable de type référence n’ayant pas de valeur.

Elles ont été introduites pour la première fois en 1965 au sein du langage ALGOL. Leur créateur, Tony Hoare, a publiquement qualifié son « invention » de « mauvaise idée historique » en raison du coût exorbitant qu’elles ont eu sur l’industrie du développement. Il s’est même risqué à en donner une estimation grossière lors d’une conférence donnée à Londres en 2009 : entre 1 et 10 milliards de dollars ! Et ces valeurs sont encore probablement en deçà de la réalité...

La vidéo de la conférence est disponible à l’adresse suivante : https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ (en anglais)

Bien qu’elles puissent se révéler extrêmement pratique au quotidien, les références nulles ont un inconvénient majeur : il faut les prendre en compte partout ! Tout oubli peut se solder très rapidement par une exception spécifique, connue dans le monde .NET sous le nom de NullReferenceException. Ce type d’erreur est probablement celle que les développeurs rencontrent le plus au long de leur carrière, aussi bien en phase de développement que sur les applications en production. C’est pour cette raison que l’équipe en charge du compilateur C# s’est penchée sur le sujet et a introduit le concept de références non-nulles avec .NET Core 3.0.

1. NullReferenceException

Ce type d’exception est très fréquent tout au long du cycle de vie logiciel pour une raison évidente : elle est extrêmement simple à produire. En effet, une NullReferenceException est levée dès lors que l’on essaie d’accéder à un membre d’un objet dont la valeur est null. Comme nous l’avons déjà...