21

Is it possible to get a method's return value in the Visual Studio debugger, even if that value isn't assigned to a local variable? For example, I'm debugging the following code:

public string Foo(int valueIn)
{
    if (valueIn > 100)
        return Proxy.Bar(valueIn);
    else
        return "Not enough";
}

Since I'm not setting any local variables in Foo, and assuming I'm not setting a break point in whatever's calling Foo, is there a way to see what the return value is if I have a breakpoint inside of Foo (or another way)? I don't have much experience with the Autos or Intermediate windows, so I'm not sure if those are even a valid option or not.

TrueWill
  • 25,132
  • 10
  • 101
  • 150
Bullines
  • 5,626
  • 6
  • 53
  • 93
  • See also [this question](http://stackoverflow.com/questions/268048/can-i-find-out-the-return-value-before-returning-while-debugging-in-visual-studio) – Dimitri C. Sep 07 '10 at 09:26
  • 3
    [This feature is new in VS2013](http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/27/seeing-function-return-values-in-the-debugger-in-visual-studio-2013.aspx). – anton.burger Jun 28 '13 at 07:44
  • [This](http://stackoverflow.com/questions/268048/can-i-find-out-the-return-value-before-returning-while-debugging-in-visual-studi) question can also help. – RBT Nov 21 '16 at 06:24

8 Answers8

5

You can always switch to disassembler view and step through the individual instructions. The return value will be in @eax (or @rax) just before you execute the 'ret' instruction.

Rob Walker
  • 46,588
  • 15
  • 99
  • 136
  • ...Or after that! E.g. after pressing F10/Shift-F11/the cursor returns to the parent function. This is good when returning a value type. The problem is, the value may be a pointer which are useless without dereferencing. – ivan_pozdeev Jan 27 '14 at 10:05
5

You can set a breakpoint in Foo, open the immediate window and run the following command:

? Foo(valueIn)

This will print the return value in the Immediate Window.

You can also copy the expression and paste it into the Watch window, though I would do this only if I am certain that the call has no side effects (otherwise you can get confusing results).

Fredrik Mörk
  • 155,851
  • 29
  • 291
  • 343
  • 15
    This will execute the function again, which is not necessarily a good idea. – SLaks Nov 09 '09 at 22:32
  • 2
    Using `$ReturnValue` Visual Studio debugger variable in quick-watch window or immediate window is much better and no risk idea. Have a look [here](http://stackoverflow.com/questions/268048/can-i-find-out-the-return-value-before-returning-while-debugging-in-visual-studi) – RBT Nov 21 '16 at 06:26
3

The answer to a similar question out there: Since Visual Studio 2013, you can add the variable $ReturnValue to the watch list. It contains the actual return value from a function.

Credits to Jesper Jensen.

Evgeni Nabokov
  • 2,421
  • 2
  • 32
  • 36
2

No, I don't know of a way to do this. I would put a breakpoint in the caller and look at the return value there.

David
  • 34,223
  • 3
  • 62
  • 80
2

You can also highlight any expression in the debugger and right-click -> quick watch. That will execute the expression (assuming it's valid) and give you the value.

Matthew
  • 2,210
  • 1
  • 19
  • 30
2

Visual Studio 2013 now has the ability in the Autos window to display the last value returned by a function, alleviating the need to re-execute it in the Output window or introduce a temporary variable:

http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/27/seeing-function-return-values-in-the-debugger-in-visual-studio-2013.aspx

Bullines
  • 5,626
  • 6
  • 53
  • 93
0

You can always use your watch box to evaluate function calls.

Foo(valueIn);

This will only work if your Proxy.Bar(valueIn) is time independent though.

Will
  • 609
  • 2
  • 8
  • 17
0

A workaround is to use a Pascal-style result variable:

public string Foo(int valueIn)
{
    string result;
    if (valueIn > 100)
        result = Proxy.Bar(valueIn);
    else
        result = "Not enough";
    return result;
}

This is good style in my opinion for longer functions. For very short ones like the one above it could be considered overkill, but it does get around the debugger problem.

dan-gph
  • 16,301
  • 12
  • 61
  • 79