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.