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.

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.

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.

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.

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.

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.

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 :

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 :

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 :

...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) :
 

 

Bon, avec ça, vos applications n'ont plus aucune excuse pour se planter sur une erreur, quelle qu'elle soit.

Et vous non plus.