Pomme Courge Mobylette

Lancement du programme

Le programme doit être lancé sous debugueur, et pas juste tout seul. Les outils ont une fenètre permettant de préparer la configuration de lancement, en lui passant les paramètres de la ligne de commande, ou les variables d'environnement. Pour java et C++, il y a une option de compilation permettant de rajouter des informations utile pour le debugage : numéros de ligne correspondant, nom des méthodes et des des variables ... Sans ces informations, pas la peine de tenter de debugger (tips pour les dinos de la ligne de commande, c'est souvent -g.

Mais afin d'être plus didactique, je vais vous montrer sur une capture d'écran eclipse, dans la perspective de debug :

Le premier outil capital est le breakpoint ou point d'arrêt. Cela permet de pointer une ligne dans le programme et de dire : "fait une pause ici" lors de son exécution. Le programme se fige, et on se retrouve dans la vue debug d'eclipse. Voyons ses composants, classiques dans tous debuggueur.

En bas, on retrouve le code source, avec en surbrillance la ligne courante. Là, elle est sur le point d'arrêt que j'avais positionné avant le lancement du programme, on le voit à la petite boule bleue dans la colonne de gauche.

En haut à gauche, la pile d'appels, ou stacktrace. Avec les imbrications de méthodes qui ont permis d'arriver là. On voit que l'exemple est rentré par le main de MyDebugTest, avant d'aller dans la méthode operation de cette même classe. On voit aussi l'ensemble des threads d'une application, en cas de traitements parallèles. On notera que java a toujours des threads de traitement interne, ne nous y intéressons pas.

Enfin en haut à droite, c'est l'affichage des variable. On retrouve les différentes variables accessible depuis l'endroit courant, ainsi que leur valeurs. Pour les objets complexes comme les classes (ici this) on peut les ouvrir pour inspecter le contenu plus en détails. A noter qu'il y a une vue watch, ou on peut taper des expressions plus complexes, y compris appelant des méthodes. Cela permet de bien voir l'état de chacune des variables du programme, et donc de vérifier que son état courant est bien l'état attendu. Par beoin de faire des "prints" qui ralentissent

Et en plus, ça bouge. Avec les commandes de contrôle du programme, on peut le faire avancer pas au pas. Petits pas ou grands pas suivant les besoins.

Tous les debugger ont ces commandes permettant d'avancer pas à pas dans le programme. De gauche à droite :

• run pour relancer le programme... jusqu'au point d'arrêt suivant.
• suspend pour suspendre l'exécution du programme, comme s'il tombait sur un point d'arrêt.
• stop pour arrêter le programme (en le tuant).
• disconnect hors du scope de cette présentation
• step into pour rentrer dans une sous-fonction, si bien évidemment, il y en a une
• step next pour passer à l'instruction suivante de la même méthode. Si l'instruction est un appel de méthode, on ne suis pas son contenu, mais il est tout de même exécuté.
• step out fini l'execution de la méthode courante, et s'arrête à nouveau dans le méthode appelante
• drop to frame permet de ramener l'exécution au début de la méthode actuellement sélectionnée dans la pile d'appel.

Sachant qu'en plus, on peut poser des point d'arret conditionnel (l'arrêt ne s'effectue que si une condition est vérifié) ou sur la levée d'une exception, on peut vraiment s'arrêter sur LE cas qui pose problème. De plus, java supporte les modification de code à la volée (sous la condition de ne pas changer la structure des classes. Le debugger est un outil qui rend bien service.

Maintenant, il est clair que cet outil est un outil bien pratique, largement plus efficace que le debug au print que l'on voit trop souvent. Mais attention de l'utiliser pour bien comprendre ce qui se passe dans le programme, et de ne pas en profiter pour rajouter un cas juste pour un bug vu ici ou là.