views:

1910

answers:

10

Take the following function:

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

When I set a breakpoint in this function, is there a possibility to inspect the returned value? The "go" function is directly coupled to a datagrid in an aspx page.

The only way to inspect the returned datatable, is to use a temporary variable... However, that's a bit inconvenient. Isn't there another way?

+8  A: 

Not that I know of. Note that if you do add a variable, it will get removed by the compiler in release builds anyway...

Marc Gravell
Nice comment, but not an answer ;-)
doekman
@doekman - I disagree; it *is* an answer (and AFAIK it is *the* answer) - it simply isn't what you wanted to hear.
Marc Gravell
I guess you are right. You might want to state: There isn't, including Visual Studio 2005, 2008 and 2010. Now the emphasis of your answer is about optimization...
doekman
orip
A: 

You could try selecting "someTableAdapter.getSomeData();", right clicking on it and go for Quick Watch.

Yann Semet
A: 

You can also ask to evaluate the value in the intermediate window as well, if it does not set flags or other variables, but only returns something.

Biri
Doesn't work with lambdas, screwing this solution royally :(
romkyns
You need to include the lambda in the question, as I use the immediate window too sometimes
Chris S
+5  A: 

Step out of the go() method using Shift-F11, and then in the "Autos" debug window it will show the return value of the method call which just popped off the stack (in this case, the go() method which is what you want). This is the behaviour in Visual Studio 2005; I haven't used Visual Studio 2008 so I don't know if this behaves the same way in that version.

LeopardSkinPillBoxHat
I've tried this in both VS2005 and VS2008, but I don't really see it. I have the "Autos" window open, but when in the "go" function, the autos-window is just empty. Also when stepping out of the function (the closing curly brace of the function is yellow). Can you give me one more hint?
doekman
I would expect the Autos-window to be empty while INSIDE the go() function. You need to step COMPLETELY OUT of the function (i.e. the debug cursor should be pointing to the function which has CALLED go()) and then you should see the return value for go() in the Autos window.
LeopardSkinPillBoxHat
@LeopardSkinPillBoxHat: can't get this to work, even with your extra hint. Are you trying this in Visual Basic? It appears to have better support for observing and changing return values...
romkyns
@romkyns - No, I did this with C++ code.
LeopardSkinPillBoxHat
@romkyns - What shows up in the "Autos" window for you? Doesn't it show a line indicating what the last called function returned?
LeopardSkinPillBoxHat
@LeopardSkinPillBoxHat: no, it doesn't do that in C#. P.S. Wow, took me a while to see this again.
romkyns
A: 

Open the Debug-Autos window gets you close. It won't show the actual return value, but will show what was evaluated in the return statement.

GeekyMonkey
Couldn't get VS2008 autos window to show anything like that. Could you please clarify?
romkyns
A: 

The only way I know, is to place a breakpoint on the return line and then call the Quick Watch Window and enter the returned expression :

someTableAdapter.getSomeData();

But this only works if the call does not change the state of any object (since there will be a second call to the same method when you will resume the execution).

Sylvain
This also only works if your expression doesn't have lambdas.
romkyns
A: 

Drag and drop the return expression into a watch window.

Eg: In the statement

return someTableAdapter.getSomeData();

drag and drop

someTableAdapter.getSomeData()

into a watch window and you'll see the value.

You can do this for any expression.

Pita.O
The problem with that: the expression is evaluated twice.
doekman
And watch expressions can't contain lambda expressions, which I use a fair bit.
Steve Crane
+2  A: 

There are a lot of work arounds, but none seems satisfactory.

To quote John Skeet below:

Still looks inconvenient to me - especially if you don't know which return value you're going to need before you start debugging. I really don't want to have to have a temporary variable cluttering up my code every time I ever return anything.t

In theory, the debugger could have a return-variable. After all: it's just a variable on the stack:

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

So consider this an feature request for Visual Studio.

doekman
@doekman - there's quite a big a difference between a variable (a well-defined local) and a value on the stack. It is a value on the stack, but it isn't a variable (=local).
Marc Gravell
A: 

Microsoft Visual C++ used to do this, but Visual Studio doesn't AFAIK.. :(

Sprintstar
+2  A: 

This isn't possible with Visual Studio 2010 or earlier for C# code. According to a Connect bug report, this was possible for VB.NET under VS2008 but no longer works for VS2010. It's been available to C/C++ developers for some time.

I've logged this as a suggestion on Connect. Please vote for it if you want this improved in future Visual Studio versions!

Alex Angas