11

I looked through SO but couldn't find the answer, I'm sure it's there though...?

While debugging, how do I get the value of the return statement if I put a breakpoint on it? I like to condense to a single line just so it looks "pretty". But I currently don't since I can't figure out how to debug the returned result...?

using (IUnitOfWork context = new EFUnitOfWork())
{
    var repo = new ReportRepository(context);
    return repo.GetProcedureReport(startDate, endDate).ToList();
    //return result.ToList();
}
David Robinson
  • 77,383
  • 16
  • 167
  • 187
MisterIsaak
  • 3,882
  • 6
  • 32
  • 55
  • This is a personal opinion, but I believe if you're even considering modifying the style of your code with debugging in mind that you're relying too much on the debugger. You should generally understand your code well enough to never have this question in the first place. – Jordan Kaye Mar 04 '13 at 22:26
  • 3
    @JordanKaye: To be fair, the computation of `GetProcedureReport` could be quite complex, and the return value may not be stored on the other side of the method call. But I would agree that you should not modify your base code just to simplify debugging. – Guvante Mar 04 '13 at 22:28
  • 2
    And we should all be absolutely perfect in every aspect of our code. Sometimes it's just not that simple! – Corey Adler Mar 04 '13 at 22:28
  • 1
    Some duplicate questions: http://stackoverflow.com/questions/1704268/getting-a-methods-return-value-in-the-vs-debugger and http://stackoverflow.com/questions/11415847/inspecting-the-returned-value-of-a-function-on-the-return-line-of-a-method-in-vi – Chris Sinclair Mar 04 '13 at 22:56
  • If you are just trying to debug this issue to figure out what's going wrong, so you feel that examining the return value right after it's called is of value to you, then there is nothing wrong with using a temporary var to capture the results of the function call and then return it. In fact I would go so far as to say that you absolutely *should* modify your coding style to make debugging as easy as possible; you never know when you will be looking at this in 3 year's time when something has gone wrong and trying to figure out wtf is going on... – Stephen Byrne Mar 04 '13 at 23:51
  • 1
    This is what I was looking for: http://stackoverflow.com/questions/268048/can-i-find-out-the-return-value-before-returning-while-debugging-in-visual-studi Thanks for the links @ChrisSinclair – MisterIsaak Mar 06 '13 at 14:17

3 Answers3

18

In VS 2013, you can add the variable $ReturnValue to the watch. It contains the actual returnvalue from the function.

Jesper Jensen
  • 835
  • 8
  • 16
  • 2
    This should be the best answer. I do not want to change code creating an unnecessary variable just to watch a return value. – Evgeni Nabokov Aug 18 '17 at 18:28
5

Select the method and right-click. Select Quickwatch from the menu.

enter image description here

I'm assuming you cannot put a breakpoint within GetProcedureReport?

Community
  • 1
  • 1
IAbstract
  • 19,551
  • 15
  • 98
  • 146
  • 1
    Yep, not being able to put a breakpoint in the method is one example. Another would be if `GetProcedureReport` has multiple return statements inside it (which I'm not a fan of). Mine deals with `EF` which makes it more convoluted of course. – MisterIsaak Mar 04 '13 at 22:54
  • What is the return type of `GetProcedureReport`? – IAbstract Mar 05 '13 at 01:07
4

The type of return value debugging you're attempting is simply not possible with managed languages like C#. The C++ debugger provides this information, via the autos window, but not managed languages.

The primary reason why is that the CLR debugging engine simply doesn't provide this value. For C#, VB or F# to provide this they would need to rewrite every return statement to spill the value into a temporary and then return the temporary. Return value debugging could then be achieved by surfacing this temporary in the debugger.

var returnTemp = repo.GetProcedureReport(startDate, endDate).ToList();
return returnTemp;

This would work but it would provide negatives to the code. Most notably that big struct values would end up being copied twice and contribute negatively to performance. Additionally this rewrite would need to occur at compile time and would affect every method being compiled. It would be much less impactful if it could be done on demand at debug time. The negatives just out weigh the benefits here.

Note that VB.Net does provide return value debugging to a small degree. I've blogged about how that works here

http://blogs.msdn.com/b/jaredpar/archive/2011/01/12/why-the-debugging-difference-between-c-and-vb-net-return-values.aspx

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454