How to debug VB.NET calculated Function Returns without a return variable

Question

It's often the case that I can write a nice tight little VB.NET function, and when it comes time to do the Return statement, it's really natural to just return the result of a quick calculation or a method call. However, this makes it difficult if I need to step through the debugger to see what is going to be returned from that Function. For example, take this simple method to illustrate the concept:

Public Shared Function GetAge(ByVal dob As DateTime, ByVal asOfDate As DateTime) As Integer
   If asOfDate.Date < dob.Date Then Return 0
   Dim factor = If(asOfDate.DayOfYear < dob.DayOfYear, 1, 0)
   ' What's going to be returned?
   Return asOfDate.Year - dob.Year - factor ' Imagine that this could be a more complicated calc, or one with side-effects that would prevent me from running it in the immediate window
End Function

I've found myself altering the way I write code just to make debugging easier. So that method would become:

Public Shared Function GetAge(ByVal dob As DateTime, ByVal asOfDate As DateTime) As Integer
   If asOfDate.Date < dob.Date Then Return 0
   Dim factor = If(asOfDate.DayOfYear < dob.DayOfYear, 1, 0)
   Dim result = asOfDate.Year - dob.Year - factor ' I made this variable just for setting a debugging breakpoint
   Return result ' I can now set a breakpoint here, but it seems awkward
End Function

Is there something I'm missing in the debugger that would make it easier to see what a method is going to return rather than always making a result variable or hopping back to the caller to see what came out? It seems awkward to alter the way code is written just to make a simple debugging task easier - it feels like I must be missing something.

Answer 1

You can set the breakpoint at the End Function line and hover the cursor over the function name.

Answer 2

I'd be inclined to go one step further and remove the Return 0 on the first line of the function so that the only place your code exits the function is at the end.

Public Shared Function GetAge(ByVal dob As DateTime, ByVal asOfDate As DateTime) As Integer
   Dim result = 0
   If asOfDate.Date >= dob.Date Then
      Dim factor = If(asOfDate.DayOfYear < dob.DayOfYear, 1, 0)
      result = asOfDate.Year - dob.Year - factor
   End If
   Return result
End Function

Done this way you only have to worry about one exit point - which makes understanding your code easier, so less debugging - and you get your break-point for free!

Answer 3

Yes, it is awkward. Visual Studio 6 could do this but that got lost in later releases. It isn't that easy to implement, how managed code returns a value is an implementation detail of the JIT compiler. It is kinda obvious for simple return value types like Integer or objects but it gets convoluted when a method returns a structure or decimal.

There isn't really anything wrong with storing it in a variable first, the JIT optimizer will get rid of that variable in most cases. But yes, it looks fugly in the source code.

There is one trick you could use if the return value type is simple, like an integer. Set a breakpoint on the End Function statement, then use Debug + Windows + Registers to display the CPU register values. The EAX register contains the value. Right-click the window and choose Floating point. The ST0 register contains a floating point return type value in 32-bit mode.

Not great, but something to get by when in a pinch.