Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Visual Studio Discussion :

VS2017 - Impossible de déboguer


Sujet :

Visual Studio

  1. #1
    Membre habitué
    VS2017 - Impossible de déboguer
    Bonjour à tous,

    Impossible de revenir en arrière dans mon code en debug lorsque je rencontre un point d'arrêt.
    Sachant que mon point d'arrêt est situé dans un catch.

    J'ai ce message:


    Une idée ?

  2. #2
    Inactif  
    Bonjour,

    Ton message d'horreur te donne deux exceptions possibles. Je serais tenté de mettre ces deux exceptions dans mon bloc Try, avec des messageBox pour afficher le message d'erreur, si jamais il y en an. D'un coup que cela donnerait quelque chose.

    Ou bien exécuter le bloc try au pas-à-pas.

    Sinon, je ne sais pas
    À ma connaissance, le seul personnage qui a été diagnostiqué comme étant allergique au mot effort. c'est Gaston Lagaffe.

    Ô Saint Excel, Grand Dieu de l'Inutile.

    Excel n'a jamais été, n'est pas et ne sera jamais un SGBD, c'est pour cela que Excel s'appelle Excel et ne s'appelle pas Access junior.

  3. #3
    Membre du Club
    Vous ne pouvez pas revenir en arrière lorsque vous déboguez. Vous ne pouvez que progresser vers l'instruction suivante.

  4. #4
    Expert éminent sénior
    Salut

    Citation Envoyé par phil.o Voir le message
    Vous ne pouvez pas revenir en arrière lorsque vous déboguez. Vous ne pouvez que progresser vers l'instruction suivante.
    ça ne fonctionne pas dans tous les cas de figure, mais lorsque tu es sur un breakpoint amuse-toi à faire remonter la flèche jaune avec ta souris et tu verras que tu iras en arrière (il y a certainement un bouton qui permet de le faire sans la souris)

  5. #5
    Membre habitué
    C'est exactement ce que je fais mais c'est en remontant avec la flêche jaune que j'ai cette erreur ... Par contre a d'autre breakpoint j'arrive à le faire ...

  6. #6
    Membre du Club
    Citation Envoyé par Max Voir le message
    ça ne fonctionne pas dans tous les cas de figure, mais lorsque tu es sur un breakpoint amuse-toi à faire remonter la flèche jaune avec ta souris et tu verras que tu iras en arrière (il y a certainement un bouton qui permet de le faire sans la souris)
    Ok, je ne m'étais jamais amusé à ça. Ce n'est pas parce qu'on peut le faire qu'on devrait le faire, en même temps. Aller en arrière implique bien plus que remonter d'une ligne; cela implique d'annuler tout changement à la pile/au tas, ce qui peut s'avérer extrêment complexe si une fonction a été appelée entre temps. De plus, débogger c'est suivre le cheminement du code lorsqu'il s'exécute, et cette exécution, elle, est toujours à sens unique. Enfin, l'on voit bien que dans le contexte où une exception a été levée, cela ne fonctionne plus du tout.
    Je m'interroge donc sur la judiciosité d'une telle action.

  7. #7
    Expert éminent sénior
    Citation Envoyé par phil.o Voir le message
    Ok, je ne m'étais jamais amusé à ça. Ce n'est pas parce qu'on peut le faire qu'on devrait le faire, en même temps ... Je m'interroge donc sur la judiciosité d'une telle action
    Ce n'est pas parce que tu ne connais pas que ce n'est pas judicieux ou dangereux de l'utiliser Pour ton information, c'est une fonctionnalité présente dans la plupart des IDE du marché, on peut donc en déduire que c'est quelque chose d'utile dans la boîte à outils d'un développeur (de surcroît, on parle ici d'aller en arrière, mais cela permet également de sauter des instructions, bref on peut aller dans les deux sens).

    Citation Envoyé par phil.o Voir le message
    Aller en arrière implique bien plus que remonter d'une ligne; cela implique d'annuler tout changement à la pile/au tas, ce qui peut s'avérer extrêment complexe si une fonction a été appelée entre temps. De plus, débogger c'est suivre le cheminement du code lorsqu'il s'exécute, et cette exécution, elle, est toujours à sens unique.
    On utilise ce genre de fonctionnalité en connaissance de cause, donc on sait ce que ça implique, ça n'a rien de complexe ni de dangereux. Tu sais que lorsqu'on est sur un point d'arrêt, on peut modifier à chaud des valeurs via la fenêtre "Watch", qu'on peut créer de nouvelles variables/exécuter du code via la fenêtre "Immediate Window" ? La prod oui c'est à sens unique, mais pas le debug, c'est à ça que c'est utile, jouer à l'apprenti sorcier et faire tout et n'importe quoi avec l'exécution de son code (vive le debug )

    Citation Envoyé par phil.o Voir le message
    Enfin, l'on voit bien que dans le contexte où une exception a été levée, cela ne fonctionne plus du tout.
    Ce qui est logique vu la teneur du message qu'il reçoit (si parmi ce qui est listé, le problème vient par exemple d'une StackOverflowException non gérée, on ne peut pas non plus demander au débuggeur de s'en sortir). D'une façon générale, une exception non gérée "casse" ta session de debug

    => Pfeffer : essaie de catcher séparément les deux exceptions proposées pour voir laquelle t'embête, regarde aussi ton Call Stack pour voir d'où c'est parti

  8. #8
    Membre habitué
    Merci Max, en effet j'utilise toutes ces fonctions, revenir en arrière, sauter une instruction, watch pour modifier une valeur de variable et créer volontairement des situations pour tester un scénario ... Il est génial cet IDE sauf que pour cette situation ça ne fonctionne pas. Je vais pousser ta solution pour voir.

    Pour finir, c'est vraiment sympatique de revenir en arrière quand tu tombes dans un catch pour connaitre la valeur de tes variables au moment ou l'erreur se génère et pour identifier l'instruction a l'origine de l'erreur.

###raw>template_hook.ano_emploi###