Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Introduction
============
Dans les exercices suivants, chaque petit programme comporte une
erreur, qui
apparait lors du test. L'objectif est d'apprendre à utiliser le débugger
pour Java d'IntelliJ pour trouver la cause de l'erreur, et la corriger.
La tâche Gradle permet de lancer les tests, mais on préfèrera cette fois
lancer uniquement le test de l'exercice en cours. Pour cela, ouvrir le
fichier contenant le test, trouver la méthode de test, et dans la marge
`clic gauche` sur l'icône de lancement ,
et choisir l'option *debug* .
Pour arrêter le débugger à une instruction du programme, il faut placer des
*breakpoints* . Il suffit
pour cela d'un `clic gauche` dans la marge du programme, sur le numéro de
ligne. Un `clic droit` permet de le paramétrer si nécessaire, et un deuxième
`clic gauche` le fait disparaître.
Lorsque le programme s'exécute, il s'interrompt automatiquement aux
breakpoints, et affiche l'état de la pile.

Dans la partie gauche se trouve la liste des *frames*, c'est-à-dire des
niveaux ou couches de la pile, la plus récente en haut. Attention, lancer un
test demande un grand nombre d'appels de méthode avant d'arriver à la
méthode de test, donc la plupart des *frames* ne sont pas pertinents, seuls
les frames les plus hauts, pour lesquels on reconnaît les méthodes du projet,
nous intéressent.
La partie droite affiche le contenu du frame courant, en commençant par la
valeur de `this` (si la méthode n'est pas statique), puis toutes les
variables et leurs valeurs. Les tableaux et les objets peuvent être
inspectés en dépliant les arborescences.
La barre du haut contient les actions réalisables, dont voici les plus
importantes.
 relance le test depuis le
début, toujours en mode *debug*.
 arrête l'évaluation du
programme immédiatement, et ferme le débuggeur.
 reprend l'évaluation,
jusqu'au prochain *breakpoint* ou la fin normale de l'exécution du programme.
 passe à l'instruction
suivante, en ignorant tout appel de méthodes dans l'instruction en cours.
 passe à la première
instruction d'une méthode appelée dans l'instruction en cours. En cas de
choix entre plusieurs méthodes (ou constructeurs), il faut cliquer sur celle
qui nous intéresse. Il est conseillé de ne pas entrer dans les méthodes ne
faisant pas partie du projet.
 reprend l'exécution jusqu'à
terminer la méthode actuellement en cours, et s'interrompt à l'instruction
ayant appelé la méthode.
Ces actions permettent d'exécuter le programme pas-à-pas, plus ou moins
finement, en inspectant les valeurs des variables.
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
Ce petit exercice vous permet de prendre en main le débugger d'IntelliJ.
- Vérifier que la méthode exécutable `main` de la classe `Main` (fichier `fr.
univamu.progav.Main.java`) appelle bien la méthode `exoDebug` d'une instance de
la classe `DebuggerTutorial` (sinon appeler l'enseignant).
- Exécuter le programme (tâche gradle run). Le programme doit afficher :
```
In method f.
In method g.
The end.
```
- Placer un *breakpoint* sur la première
ligne de la méthode 'main' (comment ? lire ci-dessus). Relancer le programme
en mode debug (bouton  en haut
à droite). À l'issue de la compilation, vous obtiendrez l'ouverture de la
vue du debugger.
- Inspecter l'objet `this`. Quelles sont ses propriétés et leurs valeurs ?
Ceci correspond-il bien au programme écrit ?
- Avancer l'exécution d'une instruction
. Quel est l'effet de
l'instruction ?
- Entrer dans l'exécution de la méthode `f`
. Combien la pile
a-t-elle de couches ? Quelles sont les valeurs de la variable `x` dans les
différentes couches de la pile ?
- Ressortir de la méthode `f`
. Exécuter l'instruction
créant une instance de la classe `A` et vérifier son effet sur la mémoire.
Quelle est la référence du nouvel objet ?
- Sauter l'appel de la méthode `g`
.
- Ajouter un breakpoint après la boucle, puis reprendre l'exécution du
programme .
- Continuer jusqu'à voir le message de victoire dans le débugger. Sinon
recommencer.
Exercice 2
==========
Dans la classe `People`, la méthode `whereIsCharlie` devrait retourner la
position de Charlie, 25 ans, dans la liste. Utiliser le test et le débuggeur
pour trouver l'erreur.
==========
Dans la classe `ASimpleLoop`, la méthode `nonTerminatingSum` fait un calcul,
qui ne termine pas. Utiliser le test et le débuggeur, pour comprendre
pourquoi elle ne termine pas. Corriger ensuite la méthode pour que le calcul
s'arrête,
==========
Dans la classe `Ratio`, représentant les nombres rationnels, l'addition ne
semble pas produire le bon résultat. Pourtant, nous avons pris soin de bien
réduire les fractions en calculant le plus grand commun diviseur avec
l'algorithme d'Euclide, et de forcer cette réduction dans la méthode
statique `of` que nous utilisons pour construire les fractions. Pour être
sûr de bien tester, nous avons aussi ajouter une méthode `unsafeOf`, qui
ignore l'étape de réduction : ainsi les valeurs attendues dans les tests
sont certainement bien définies (nous les avons réduites nous-mêmes). Enfin,
la méthode de test d'égalité profite de la forme réduite : il suffit de
tester l'égalité des numérateurs et des dénominateurs. Utiliser la méthode
de test et le débuggeur pour trouver l'erreur et la corriger.
==========
La classe `GuessingGame` reprend la stratégie optimale pour le jeu
consistant à trouver un entier d'un intervalle (par exemple entre 1 et 1000),
en tentant des valeurs, et en obtenant pour chaque mauvaise réponse une
indication "plus petit" ou "plus grand". Bien sûr, il s'agit de faire une
recherche dichotomique. Ici, une erreur a été faite, et la dichotomie ne
termine pas toujours. Il va d'abord falloir trouver une valeur mystère pour
laquelle l'algorithme boucle infiniment (provoquant un dépassement de pile).
Ensuite, en utilisant le débuggeur et en partant avec cette valeur, il sera
possible de repérer la raison pour laquelle l'algorithme boucle ainsi.
Utiliser donc une fois de plus le débugger pour trouver et corriger l'erreur.