Une remarque pertinente ?
Une critique impertinente ?
Un lynchage en règle ?
Une invitation sous les tropiques ?

Ecrivez-moi !
Conçu et enseigné tel qu'en lui même, avec pertes, fracas et humour de qualité supérieure            
 par Christophe Darmangeat dans le M2 PISE du Master MECI (Université Paris 7)            

 
 
 
  
 
 
 
Partie 9
La chasse aux bugs
 
Programmer est une activité fort distrayante, mais chacun sait que ce n'est jamais que le meilleur moyen pour faire un élevage de bugs. Si on veut que l'application fonctionne, il reste, après l'avoir écrite - et en partie, tout en l'écrivant - le délicat problème d'exterminer méthodiquement les vilaines petites bêbêtes qui nous pourrissent l'existence. à cette fin, VB.NET propose un certain nombre d'ustensiles qu'il serait bien présomptueux de négliger.
Les bugs se répartissant en trois différentes espèces, et chacune ayant des moeurs différentes, les techniques de chasse, les appâts et les pièges devront être adaptées à chaque type de bestiole.
1. Les erreurs de syntaxe
Nous avons vu que l'éditeur de code de Visual Basic signalait en temps réel les erreurs de syntaxe (et plus généralement, les erreurs de compilation), et qui plus est, qu'il précisait la nature de ces erreurs, sous forme d'info-bulle. De ce côté, donc, pas de souci, voilà une affaire réglée : les bugs de syntaxe seront la première espèce à être repérée, puis exterminée par vos bons soins. Je ne m'appesantis donc pas sur ce point.
2. Les erreurs de logique
Là, c'est tout de suite une autre paire de manches. Rappelons en effet que l'erreur de logique, animal sournois s'il en est, ne provoque pas à proprement parler un plantage de l'application, ou tout au moins, pas forcément. Elle peut aussi se contenter de générer un résultat aberrant, ou tout simplement faux, ce qui la rend d'autant plus difficile à débusquer qu'elle peut passer inaperçue.
Ainsi, une erreur consistant à faire un tour de boucle de trop dans le balayage du tableau se repèrera immédiatement par le plantage du programme. Mais une erreur de calcul de 4,23 % dans le surcoût de l'échelon inférieur de la prime d'huile de l'ouvrier qualifié à l'échelon 543 modifié 42-B, il faut parfois être vigilant pour la repérer.
Remarque utile :
Avant toute chose, il faut vérifier que l'intégralité des outils de déboguage de VB a bien été mise en service, en allant dans le menu Projet - Propriétés du projet et en allant cocher la case Générer les informations de débogage si tel n'était pas le cas.
Toujours est-il que pour traquer toute cette engeance, VB propose plusieurs armes redoutables, pour la plupart disponibles notamment dans la barre d'outils Déboguer.
  • L'exécution pas à pas : pour commencer, la première question qu'il convient de se poser (et qu'on oublie trop souvent) : le programme passe-t-il bien sur les lignes d'instructions que nous avons écrites, et le fait-il au bon moment ? Un bon moyen de le savoir est de demander une exécution pas à pas. L'exécution ira alors de ligne en ligne, en n'avançant que lorsque nous lui en donnerons l'ordre formel, via la touche F8. Cette technique permet de repérer tout de suite les procédures dans lesquelles on ne rentre pas, et les mauvais branchements en général.
  • Le point d'arrêt : si on soupçonne un souci dans la procédure tout au fond en bas à droite derrière l'église, il peut être fastidieux de se fader dix minutes de pas à pas avant de parvenir à l'endroit suspect. Pour cela, une arme redoutable : le point d'arrêt, judicieusement posé d'un clic de souris dans la marge, juste avant l'endroit où les ennuis arrivent. On lance une exécution normale, qui s'interrompt au point d'arrêt. Et à partir de là, on peut y aller au pas à pas.
  • Un déboguage consiste souvent à pouvoir suivre au fur et à mesure de l'exécution les valeurs successives prises par une variable rétive. A cette fin, l'outil le plus simple et le plus puissant proposé par VB est tout bonnement... la souris ! En effet, en exécution pas à pas (et souvent, en ayant placé judicieusement un point d'arrêt), il suffit d'amener la souris au-dessus d'une variable, ou d'une expression, pour qu'apparaisse dans un petit cadre jaune, la valeur de cette variable ou de cette expression. Vous verrez, avec un peu d'habitude, c'est incroyable ce que ce petit truc peut rendre service :
3. Les erreurs d'exécution
Malgré tous nos efforts, et nos qualités de chasseurs, et même si notre code est optimisé aux petits oignons, il reste une espèce de bugs que nous ne serons peut-être pas parvenus à éradiquer  : les erreurs d'exécution.
En effet, imaginons par exemple que notre application permette d'aller chercher un fichier quelque part sur la machine, avec une boîte de dialogue du genre du très classique Fichier - Ouvrir. Même en admettant que notre code soit parfait, nickel, eh bien s'il prend l'idée à l'utilisateur d'aller chercher un fichier sur la disquette alors qu'il n'y a pas de disquette dans le lecteur, ou sur le CD-ROM alors que le lecteur est vide, notre application se vautrera lamentablement en générant un message incompréhensible, mais néanmoins très effrayant.
Or, il faut toujours garder en tête les principes fondamentaux du développeur.
Principe n°1 :
Si une action de l'utilisateur est susceptible de faire planter une application, tout utilisateur accomplira précisément cette action dans les secondes qui suivent le lancement de l'application.
Principe n°2 :
Si le développeur est convaincu qu'aucune action de l'utilisateur n'est susceptible de faire planter son application, l'utilisateur se chargera de le détromper dans les minutes qui suivent le lancement de l'application.
D'où la nécessité absolue, lorsqu'on conçoit une application à vocation un peu sérieuse, d'utiliser l'arme ultime : le piège à erreur d'exécutions, c'est-à-dire le piège à exceptions.
Définition  :
Une exception est une erreur d'exécution.
L'exception une classe de VB.Net, qui si une erreur d'exécution se produit, va générer un objet d'un type en rapport avec l'erreur.
L'idée de base, pour gérer ces erreurs, est en quelque sorte d'intercepter l'objet Exception qui sera créé en cas d'erreur, et de dire à VB ce qu'il doit faire dans ce cas. Cela s'effectue au travers d'un bloc Try ... Catch ... End Try, dont la structure la plus simple est la suivante :
Try
  instructions susceptibles de provoquer une erreur
Catch variable As TypedException
  instructions à exécuter en cas d'erreur
End Try
Remarque pertinente :
On peut écrire à la suite autant de blocs Catch que l'on souhaite.
Pour davantage de précisions sur ce point, voir quelques lignes plus bas.
On peut éventuellement ajouter à cette structure de base un bloc Finally, qui indiquera des instructions à exécuter en fin de procédure quoi qu'il se soit passé, qu'une erreur soit survenue ou non :
Try
  instructions susceptibles de provoquer une erreur
Catch variable As Type_Exception
  instructions à exécuter en cas d'erreur
Finally
  instructions finales à exécuter dans tous les cas
End Try
Tout cela permettra donc au code de retomber sur ses pieds en cas de problèmes, et de faire qu'une erreur ne se traduise pas par un plantage, mais par une série d'instructions que vous aurez prévue à l'avance et qui permettra à l'application de poursuivre normalement sa route.
Parlons maintenant plus en détail des différents types d'exceptions.
Le plus général d'entre eux est le type Exception, qui les inclut toutes. Ainsi, une ligne comme :
Catch Erreur As Exception
...interceptera toutes les formes possibles et imaginables d'erreurs d'exécution. Mais on peut souhaiter à un traitement différencié selon la nature de l'erreur. S'agit-il d'un CD-ROM absent, d'un répertoire inexistant, d'un fichier absent ? On peut alors écrire autant de blocs Catch que de types d'erreurs que l'on souhaite différencier, sachant que ces types sont définis par Visual Basic (et en réalité, par la plateforme .Net). Voici un petit échantillon des types d'exceptions disponibles (on se réfèrera à l'aide ou à un bouquin pour une liste plus détaillée) :
 
Nom du Type
Nature de l'erreur
IO.FileNotFoundException Fichier non trouvé
IO.DirectoryNotFoundException Répertoire non trouvé
IndexOutOfRangeException Indice en-dehors d'un tableau
ArithmeticException Division par zéro ou dépassement de capacité
 
Bon, avec ça, vos applications n'ont plus aucune excuse pour se planter sur une erreur, quelle qu'elle soit.
Et vous non plus.