Getting a Method's Return Value in the VS Debugger

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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.

Answer 5

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.

Answer 6

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.