Puis-je connaître la valeur de retour avant de revenir lors du débogage dans Visual Studio?

Prenez la fonction suivante:

DataTable go() {
    return someTableAdapter.getSomeData();
}

Lorsque je définit un point d'arrêt dans cette fonction, y a-t-il une possibilité d'inspecter la valeur retournée? go()est directement couplé à une grille de données dans une .aspxpage.

La seule façon d'inspecter la table de données retournée est d'utiliser une variable temporaire. Cependant, c'est un peu gênant. N'y a-t-il pas une autre façon?

Pas que je sache de. Notez que si vous faites ajouter une variable, il va être supprimée par le compilateur dans la version construit de toute façon ...

Mise à jour: cette fonctionnalité a été ajoutée à VS2013 . Vous pouvez voir les valeurs de retour dans les fenêtres d'autos ou utiliser $ReturnValuedans la fenêtre de surveillance / immédiate.

La valeur ne peut être vue directement qu'après le retour de la fonction, donc le moyen le plus simple d'y accéder est de mettre un point d'arrêt sur l'appel de fonction et de passer (F10) l'appel.

Mise à jour pour VS2015: boo! malheureusement, il ne semble pas être dans la mise à jour VS2015 (devenv v14)
pour VS2017: il est de retour. (devenv v15)

Cela peut être fait dans Visual Studio 2013 avec CLR 4.5.1 selon le site de commentaires des clients . Il n'était pas disponible dans les versions précédentes pour C #.

(Visual Studio 2008 et versions antérieures l'ont pris en charge pour VB.NET. Il a toujours été disponible pour les développeurs C / C ++.)

Je suis d'accord que c'est une chose très utile à avoir: non seulement voir la valeur de retour de la méthode avant d'en sortir, mais aussi voir la valeur de retour des méthodes que je viens de franchir. Je l'ai implémenté dans le cadre d'une extension commerciale de Visual Studio appelée " OzCode ".

Avec lui, vous pouvez afficher les valeurs de retour de méthode directement sur l'éditeur de code, comme une sorte d'affichage HUD:

Pour plus d'informations, veuillez voir cette vidéo .

Selon Microsoft, il n'y a aucun moyen de l'implémenter de manière fiable avec du code managé. C'est un problème qu'ils connaissent et sur lequel ils travaillent:

Pour ceux qui ont de l'expérience dans le débogage de code C ++ ou VB6 natif, vous avez peut-être utilisé une fonctionnalité dans laquelle des valeurs de retour de fonction vous sont fournies dans la fenêtre Autos. Malheureusement, cette fonctionnalité n'existe pas pour le code managé. Bien que vous puissiez contourner ce problème en affectant les valeurs de retour à une variable locale, ce n'est pas aussi pratique car cela nécessite de modifier votre code. Dans le code managé, il est beaucoup plus difficile de déterminer la valeur de retour d'une fonction que vous avez franchie. Nous avons réalisé que nous ne pouvions pas faire la bonne chose de manière cohérente ici et nous avons donc supprimé la fonctionnalité plutôt que de vous donner des résultats incorrects dans le débogueur. Cependant, nous voulons vous le ramener et nos équipes CLR et Debugger recherchent un certain nombre de solutions potentielles à ce problème. Malheureusement, cela ne fera pas partie de Visual Studio 11.

https://connect.microsoft.com/VisualStudio/feedback/details/597933/add-a-return-pseudo-variable-to-the-visual-studio-debugger-for-net-code

Concernant Visual Studio 2015:

Selon la réponse actuellement acceptée par Marc Gravell:

Cette fonctionnalité a été ajoutée à Visual Studio 2013 . Vous pouvez voir les valeurs de retour dans les fenêtres d'autos ou utiliser $ ReturnValue dans la fenêtre de surveillance / immédiate

Cette réponse indiquait également que cette fonctionnalité ne fonctionne pas dans Visual Studio 2015. Ce n'est pas (entièrement) vrai. Sur Examiner les valeurs de retour des appels de méthode, il y a la note suivante:

Les évaluateurs d'expressions héritées doivent être activés pour que $ ReturnValue soit reconnu (Outils / Options / Débogage / Utiliser les évaluateurs d'expressions C # et VB hérités ). Sinon, vous pouvez utiliser $ ReturnValue1 .

J'ai testé cela dans Visual Studio 2015 Enterprise:

• Avec les évaluateurs d'expressions héritées désactivés: seul $ ReturnValue1 fonctionne
• Avec les évaluateurs d'expression existants activés: à la fois ReturnValue $ et ReturnValue1 $ travail

Si vous allez dans le menu Outils → Options , IntelliTrace et modifiez le paramètre pour collecter les événements et les informations d'appel.

Vous pouvez revenir à l'événement d'appel précédent ( Ctrl+ Shift+ F11) et voir la valeur temporaire renvoyée par l'appel de méthode dans la fenêtre Autos en tant qu'enfant du nom de la méthode.

Cela ne vous montre pas la valeur de retour pour la méthode dans laquelle vous vous trouvez. Il vous montre juste la valeur de retour de la dernière méthode appelée dans la méthode actuelle.

Donc c'est bon pour

DataTable go(){return someTableAdapter.getSomeData();}

car il vous montre la valeur de retour pour someTableAdapter.getSomeData().

Mais pas pour:

int go(){return 100 * 99;}

Vieille astuce des jours pré .NET: Ouvrez la fenêtre Registres et regardez la valeur du registre EAX. Celui-ci contient la valeur de retour de la dernière fonction appelée.

Sortez de la méthode go () en utilisant Shift-F11, puis dans la fenêtre de débogage "Autos", il affichera la valeur de retour de l'appel de méthode qui vient de sortir de la pile (dans ce cas, la méthode go () qui est ce que tu veux). Il s'agit du comportement dans Visual Studio 2005; Je n'ai pas utilisé Visual Studio 2008, donc je ne sais pas si cela se comporte de la même manière dans cette version.

Oui, il y a un très bon moyen. Un inconvénient majeur est qu'il faudrait attendre 5, voire 6 ans. Depuis que je vois que vous avez posté en novembre 2008, je vous suggère de waaaaaa ...

... aaaait. Et voilà! Pour vous, MS a publié la dernière version de Visual Studio 2013, où il s'agit d'une fonctionnalité par défaut accessible à partir des menus lors de l'exécution en mode débogage (menu Debug → Windows → Autos ).

Il existe de nombreuses solutions de contournement, mais aucune ne semble satisfaisante.

Pour citer John Skeet ci-dessous (commentaire sur une réponse maintenant supprimée):

Cela me semble toujours gênant, surtout si vous ne savez pas de quelle valeur de retour vous aurez besoin avant de commencer le débogage. Je ne veux vraiment pas avoir une variable temporaire encombrant mon code chaque fois que je retourne quoi que ce soit.

En théorie, le débogueur pourrait avoir une returnvariable. Après tout: c'est juste une variable sur la pile:

unsafe {
  int * sp = stackalloc int[1];
  try {
    return a+b;
  }
  finally {
    Trace.WriteLine("return is " + *(sp+3));
  }
}

Considérez donc cela comme une demande de fonctionnalité pour Visual Studio.

Je voulais développer la réponse de PascalK pour que cela fonctionne dans Visual Studio 2015, car il existe une fonctionnalité cachée qui n'est pas documentée dans Examiner les valeurs de retour des appels de méthode .

Si vous avez des appels de fonction imbriqués, les pseudo-variables $ResultValueXsont automatiquement créées, où le X fait référence à l'ordre des appels de fonction. Donc, si vous avez un appel tel que Multiply(Five(), Six()), les pseudo-variables suivantes sont créées:

Five()     | $ResultValue1 = 5
Six()      | $ResultValue2 = 6
Multiply() | $ResultValue3 = 30

Microsoft Visual C ++ le faisait auparavant, mais Visual Studio ne fonctionne pas AFAIK .. :(

La seule façon que je sache est de placer un point d'arrêt sur la ligne de retour, puis d'appeler la fenêtre Quick Watch et d'entrer l'expression retournée:

someTableAdapter.getSomeData();

Mais cela ne fonctionne que si l'appel ne change pas l'état d'un objet (car il y aura un deuxième appel à la même méthode lorsque vous reprendrez l'exécution).

Vous pouvez également demander d'évaluer la valeur dans la fenêtre intermédiaire, si elle ne définit pas d'indicateurs ou d'autres variables, mais ne renvoie que quelque chose.

Je pense que vous pouvez le déterminer en regardant le registre RAX dans la fenêtre Registers (Debug / Windows / Registers). Après avoir quitté (SHIFT + F11) de la fonction, vérifiez le registre RAX. Je ne sais pas pour un fait, mais une fois sur une lune, vous pouvez vérifier un registre (avant les jours .NET) et y voir la valeur de retour. Il peut même s'agir d'une combinaison de RAX et RBX, etc.

L'ouverture de la fenêtre Débogage → Autos vous permet de fermer. Il ne montrera pas la valeur de retour réelle, mais il montrera ce qui a été évalué dans l'instruction de retour.

Oui, en passant à VB.NET. ; P (Vous venez de dire "Visual Studio".;)

Aussi longtemps que je me souvienne (de Visual Basic à toutes les versions de VB.NET), vous pouvez simplement interroger le nom de la fonction. Il "fonctionne" comme une variable locale qui est implicitement déclarée au début de la fonction et sa valeur actuelle est également utilisée comme valeur de retour chaque fois que la fonction se termine via des moyens de déclaration non-retour (c'est-à-direExit Function -à- ou simplement en traversant) et bien sûr, lorsque l'instruction return est utilisée.

Il est également défini sur l'expression de l'instruction return. Tout comme une variable locale, sa valeur peut être inspectée à n'importe quel point d'exécution à l'intérieur de la fonction (y compris après l'exécution de l'instruction return). C # n'a pas cela et devrait.

Cette petite fonctionnalité VB.NET (plus la Exit Functiondéclaration qu'elle active - une autre fonctionnalité que C # n'a pas et devrait) est très utile dans une forme de programmation défensive que je pratique où j'initialise toujours le nom de la fonction à la valeur d'échec / par défaut comme première déclaration. Ensuite, à n'importe quel point d'échec (qui se produit normalement beaucoup plus souvent que les points de réussite), je peux simplement appeler l' Exit Functioninstruction (c'est-à-dire sans avoir à dupliquer l'expression d'échec / par défaut ou même un nom de constante / variable).

La réponse acceptée ne fonctionne pas correctement avec Visual Studio 2015, mais en plaçant un point d'arrêt sur la dernière ligne de la méthode et en appuyant sur F10, elle mettra toutes les expressions de la valeur de retour dans la fenêtre locale.

Vous pouvez essayer de sélectionner "someTableAdapter.getSomeData();", faire un clic droit dessus et opter pour Quick Watch .

Faites glisser et déposez l'expression de retour dans une fenêtre de surveillance.

Par exemple, dans la déclaration

return someTableAdapter.getSomeData();

glisser déposer

someTableAdapter.getSomeData()

dans une fenêtre de surveillance, et vous verrez la valeur.

Vous pouvez le faire pour n'importe quelle expression.