Débogage Applications Java

Débogage Applications Java

Fenêtre Débogage
Lorsque vous déboguer un programme, la console Debogage apparaît dans un onglet dans la partie inférieure gauche de l’EDI. La console de Débogage enregiste le statut d’exécution du programme débogué (comme par exemple si le code est arrêté à un point d’arrêt). De plus, un onglet s’ouvre dans la fenêtre Output pour y enregistrer tout output de l’application (ainsi que le résultat du script Ant que l’EDI utilise pour exécuter la commande).
Dans le coin inférieur droit, certaines fenêtres (Watches, Local Variables, et Call Stack) s’ouvrent en tant qu’onglet et fournissent certaines informations concernant la session de débogage, comme la valeur actuelle des variables, et la liste des méthodes appelées. Vous pouvez également ouvrir les fénêtres de débogage individuellement en les choisissant depuis le menu Windows | Debugging.
La plupart des fenêtres affichent des informations selon le contexte actuel du débogueur. En général, le context actuel correspond à un appel de méthode dans un thread dans une session. Vous pouvez changer le contexte (par exemple, désigner un autre thread dans la fenêtre Thread) sans affecter la façon dont le programme débogué s’exécute.
Voyez le Tableau 1 pour la liste de toutes les fenêtres disponibles et comment les ouvrir.
Attacher le Débogueur à une Application en cours d’Exécution
Si vous devez déboguer une application qui s’exécute sur une autre machine ou qui s’exécute dans une machine virtuelle différente, vous pouvez attacher le débogueur de l’EDI à cette application:
1. Démarrer l’application que vous désirez déboguer en mode debug. Cela se fait en rajoutant certains arguments spécifiques au script qui lance l’application. Pour les utilisateurs de Windows qui utilisent un JDK de Sun, la liste d’arguments peut ressembler à ceci (tout sur une seule ligne, et pas d’espace après -Xrunjdwp:):
java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp: transport=dt_shmem,server=y,address=MyAppName,suspend=n -classpath C:\my_apps\classes mypackage.MyApp
Sous d’autres systèmes d’exploitation, la liste d’argument peut ressembler à ceci:
java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp: transport=dt_socket,server=y,address=8888,suspend=n -classpath HOME/my_apps/classes mypackage.MyApp
Pour une documentation plus complete de ces options, visitez la page http://java.sun.com/products/jpda/doc/conninv.html.
2. Dans l’EDI, ouvrez le projet qui contient le code source de l’application à déboguer.
3. Sélectionnez Run | Attach Debugger.
4. Dans la boite de dialogue Attach, sélectionnez le connecteur depuis la liste déroulante Connector.
Sélectionnez SharedMemoryAttach si vous désirez attacher une application qui a été lancée avec le transport dt_shem. Sélectionnez SocketAttach si vous désirez attacher une application qui a été lancée avec le transport dt_socket.
Voyez la ligne Connector du Tableau 3 pour plus d’informations sur les différents types de connecteurs.
5. Remplisser le restant des champs. Les champs qui apparaissent après Connector dépend du type de connecteur que vous avez sélectionné. Voyez le Tableau 2 pour les differents champs.
Lancer le Débogueur En Dehors de la Classe Principale du Projet
Si vous avez plusieurs classes exécutables dans votre projet, il y a des fois où vous aimeriez lancer le débogueur pour une classe différente de celle qui est spécifiée comme la classe principale du projet.
Pour lancer le débogueur sur une classe autre que la classe principale du projet, cliquez-droit sur le noeud du fichier dans la fenêtre Projects ou Files et choisissez Debug File.
Vous ne pouvez démarrer le débogueur sur un fichier que s’il possede une méthode main.
Avancer pas à pas dans le code
Une fois que l’exécution de votre programme est suspendu, vous avez plusieurs façons de continuer l’exécution du code. Vous pouvez avancer ligne par ligne (Step In) ou avec un incrément plus élevé. Voyez le tableau 4 pour les commandes disponibles pour l’exécution pas à pas ou continue .

Exécution Code Ligne par Ligne

Vous pouvez déboguer ligne par ligne en choisissant Run | Step Into (F7). Si vous utilisez la commande Step Into sur un appel de méthode, le débogueur entre dans la méthode et s’arrête à la première ligne, à moins que la méthode fasse partie d’une bibliothèque que vous n’avez pas spécifié comme devant être utilisée par le débogueur. Voyez le sujet Exécution Dans le JDK et Autres Bibliothèques ci-dessous pour les détails quant à la façon de maquer les sources disponibles pour l’utilisation dans le débogueur.

Exécution d’une Méthode Sans Y Rentrer

Vous pouvez exécuter une méthode sans que le déboguer ne marque une pause dans la méthode, en choisissant run | Step Over (F8). Après avoir utilisé la commande Step Over, le débogueur marque à nouveau une pause après l’appel de méthode.

Terminer l’Exécution Jusqu’à la Fin d’une Méthode

Si vous êtes en train de déboguer une méthode que vous ne désirez plus analyser, vous pouvez demander au débogueur de continuer l’exécution de la méthode en d’ensuite s’arrêter que sur la ligne après l’appel de méthode.
Pour terminer l’exécution d’une méthode de cette façon, choisissez Run | Step Out Of (Maj-Alt-F7).
Continuer Jusqu’au Prochain Point d’Arrêt
Si vous ne devez pas observer chaque ligne de code lors du débogage, vous pouvez continuer l’exécution jusqu’au prochain point d’arrêt ou jusqu’à ce que l’exécution soit autrement suspendue.
Pour continuer l’exécution d’un programme qui a été suspendu à un point d’arrêt, choisissez choose Run | Continue ou pressez les touches Ctrl-F5.
Continuer Jusqu’à la Position du Curseur
Lorsque l’exécution est suspendue, vous pouvez continer jusqu’à une ligne spécifique sans devoir definir de point d’arrêt, en plaçant le curseur sur cette ligne et en choisissant Run | Run to Cursor (F4).

Exécution Dans le JDK et Autres Bibliothèques

Lorsque vous êtes en train de déboguer, vous pouvez également déboguer le JDK et d’autres bibliothèques si vous en avez le code source associé. Voir le sujet Rendre les Sources Externes Disponibles dans l’EDI du chapitre Essentiel du Projet de l’EDI pour savoir comment associer le code source avec une bibliothèque.
Par défaut, l’EDI ne va pas déboguer les sources du JDK. Si vous utilisez la commande Step Into sur l’appel d’une méthode du JDK, l’EDI exécute la méthode et retourne le marqueur du programme à la ligne suivant l’appel de méthode (comme si vous aviez utilisé la commande Step Over).
Pour activer le débogage dans les sources du JDK :
1. Lancer le débogueur pour l’application.
2. Ouvrez la fenêtre Sources en choisissant Window | Debugging | Sources ou en pressant les touches Maj-Alt-8.
3. Cocher la case Use For Debugging pour le JDK.
Limiter les Classes Auxquelles Vous Pouvez Accéder Pour une Bibliothèque
Si vous utilisez une bibliothèque pour le débogage, vous pouvez mettre un filtre pour exclure certaines sources.
Pour exclure des classes d’être utilisés dans le débogueur:
1. Démarrer le débogueur pour l’application.
2. Ouvrir la fenêtre Sources en choisissant Window | Debugging | Sources ou en pressant Maj-Alt
3. Cliquez-droit sur la ligne de la bibliothèque pour laquelle vous désirez créer un filtre d’exclusion et choisissez Add Class Exclusion Filter.
4. Introduisez un filtre dans la boîte de dialogue Add Class Exclusion Filter.
Le filtre peut être :
• un nom de classe pleinement qualifié.
• Un nom de paquetage ou un nom de classe avec une astérisque (*) à la fin pour créer une wildcard. Par exemple, vous pourriez introduire ce qui suit pour exclure toutes les classes du paquetage javax.swing: javax.swing.*
• une expression avec une wildcard au début. Par exemple, pour exclure toutes les classes qui ont Test à la fin de leurs noms, vous pouvez utiliser: *Test
Vous pouvez créer plusieurs filtres d’exclusion de classes.
Pour désactiver le filtre, décocher la case Use in Debugging près du filtre dans la fenêtre Sources.
Pour supprimer un filtre d’exclusion de classes, cliquez-droit sur le filtre et choisissez Delete.

Définir des Points d’arrêts

Un point d’arrêt est un marqueur que vous définissez pour spécifier où l’exécution devrait être suspendue lorsque vous exécutez votre application dans le débogueur de l’EDI. Les points d’arrêt sont stoqués dans l’EDI (pas dans le code de votre application) et persistent entre les sessions de débogages et les sessions de l’EDI.
Lorsque l’exécution marque une pause sur un point d’arrêt, la ligne où l’exécution est suspendue est colorée en vert dans l’Editeur de Source et un message est affiché dans la Console de Débogueur avec l’information sur le point d’arrêt qui a été atteint.
Dans leur forme la plus simple, les points d’arrêt vous fournissent une façon de suspendre l’exécution du programme à un point spécifique pour que vous puissiez:
• Superviser les valeurs des variables à ce point dans l’exécution du programme.
• Prendre le contrôle de l’exécution du programme en avançant ligne par ligne dans le code, ou méthode par méthode.
Cependant, vous pouvez également utiliser les points d’arrêt comme outil de diagnostic pour faire des choses comme:
• Détecter lorsque la valeur d’un champ ou variable locale est modifiée (ce qui peut, par exemple, vous aider à déterminer quelle partie du code assigne une valeur inappropriée à un champ).
• Détecter lorsqu’un objet est créé (ce qui peut être utile, par exemple, lorsque vous essayer de pister un memory leak).
Vous pouvez définir plusieurs points d’arrêt et vous pouvez définir différents types de points d’arrêt. Le type le plus simple de point d’arrêt est un point d’arrêt de ligne, où l’exécution du programme s’arrête à la ligne spécifiée. Vous pouvez également définir des points d’arrêts pour d’autres situations, comme l’appel d’une méthode, le lancement d’une exception, ou le changement de valeur d’une variable. De plus, vous pouvez définir des conditions pour certains types de points d’arrêt pour qu’ils suspendent l’exécution du programme uniquement dans des circonstances bien spécifiques. Voyez le tableau 5 pour un résumé des types de points d’arrêt.

Définir un Point d’Arrêt sur une ligne

Pour définir un point d’arrêt de ligne, cliquez dans la marge gauche de la ligne où vous désirez mettre un point d’arrêt, ou positionnez le curseur dans la ligne et pressez Ctrl-F8.
Pour supprimer un point d’arrêt, cliquez à nouveau dans la marge de gauche de la ligne où se trouve le point d’arrêt, ou positionnez le curseur dans la ligne et pressez Ctrl-F8.
Si vous désirez personnaliser un point d’arrêt de ligne, vous pouvez le faire via la fenêtre Breakpoints. Choisissez Window | Debugging | Breakpoints ou pressez Maj-Alt-5. Dans la fenêtre Breakpoints, cliquez-droit sur le point d’arrêt et choisissez Customize.
Définir un Point d’Arrêt sur l’Appel d’une Classe
Vous pouvez définir un point d’arrêt sur une classe pour que le débogueur suspend l’exécution lorsque le code de la classe sera accédé et/ou lorsque la classe est enlevée de la mémoire.
Pour mettre un point d’arrêt sur une classe:
1. Choisissez Run | New Breakpoint (Maj-Ctrl-F8).
2. Dans la boîte de dialogue New Breakpoint, sélectionnez Class dans la liste déroulante Breakpoint Type.
3. Introduisez les noms de la classes et du paquetage. Ces champs devraient être automatiquement remplis avec la classe affichée actuellement dans l’Editeur de Source.
Conseil EDI NetBeans
Vous pouvez spécifier de nombreuses classes pour le point d’arrêt à appliquer, soit en utilisant les wildcards dans les champs Package Name et Class Name, ou en sélectionnant la case Exclusion Filter.
Utilisez l’astérisque (*) pour créer des wildcards dans les champs Package Name et Class Name si vous désirez que le point d’arrêt s’applique à plusieurs classes ou à toutes les classes dans un paquetage. Par exemple, si vous n’introduisez qu’une astérisque dans le champs Class Name, le point d’arrêt s’appliquera à toutes les classes du paquetage spécifié dans le champ Package Name. Vous pouvez utiliser l’astérisque au début ou à la fin de l’expression, mais pas au milieu.
Cochez la case Exclusion Filter si vous désirez que le point d’arrêt s’applique à toutes les classes (y compris les classes du JDK) excepté pour celles qui correspondent aux classes ou paquetages spécifiés dans les champs Package Name et Class Name. Vous pouvez définir plusieurs points d’arrêt avec le Exclusion Filter activé. Par exemple, vous pouvez définir un filtre d’exclusion sur com.mydomain.mypackage.mylib.* parce que vous désirez que le point d’arrêt de classe ne s’applique qu’à toutes vos classes excepté celles du paquetage mylib. Cependant, si vous ne désirez pas que le débogueur marque une pause au chargement de chaque classe du JDK appelée, vous devriez également mettre un point d’arrêt de classe avec un filtre d’exclusion sur java.*.

Starting a Debugging Session
Debugger Windows
Attaching the Debugger to a Running Application
Starting the Debugger Outside of the Project’s Main Class
Stepping Through Code
Executing Code Line By Line
Executing a Method Without Stepping Into It
Resuming Execution Through the End of a Method
Continuing to the Next Breakpoint
Continuing to the Cursor Position
Stepping Into the JDK and Other Libraries
Limiting the Classes That You Can Step Into For a Library
Setting Breakpoints
Setting a Line Breakpoint
Setting a Breakpoint on a Class Call
Setting a Breakpoint on a Method or Constructor Call
Setting a Breakpoint on an Exception
Setting a Breakpoint on a Field or Local Variable
Setting a Breakpoint on the Start or Death of a Thread
Managing Breakpoints
Grouping Related Breakpoints
Enabling and Disabling Breakpoints
Deleting a Breakpoint
Customizing Breakpoint Behavior
Logging Breakpoints Without Suspending Execution
Customizing Console Messages When Breakpoints Are Hit
Making Breakpoints Conditional
Working With Variables and Expressions
Setting a Watch on a Variable or Field
Monitoring the Object Assigned to a Variable
Displaying the Value of a Class’s toString Method
Changing Values of Variables or Expressions
Displaying Variables From Previous Method Calls
Backing up From a Method to its Call
Monitoring and Controlling Execution of Threads
Switching the Currently Monitored Thread
Suspending and Resuming Threads
Suspending a Single Thread at a Breakpoint
Isolating Debugging to a Single Thread
Fixing Code During a Debugging Session
Viewing Multiple Debugger Windows Simultaneously