Visual Studio debugger request: $return local variable

The previous post on the special $exception local variable was really just some background to ask for a new special local called $return that holds what is being returned by the current method (basically, the return value that’s on, or going to be, on the stack, but without having to use windbg or the like).  Certainly it would be nice if it also worked for arbitrary lambdas as well, but I’ll keep the scope of the request small for now Smile

So, here’s the hypothetical source:

Code Snippet
  1. using System;
  2. using System.IO;
  3.  
  4. class Program
  5. {
  6.     static void Main(string[] args)
  7.     {
  8.         Console.WriteLine(GetMyPath(null));
  9.         Console.WriteLine(GetMyPath("foo.txt"));
  10.     }
  11.  
  12.     private static string GetMyPath(string input)
  13.     {
  14.         if (input == null)
  15.         {
  16.             return "Invalid path";
  17.         }
  18.         return Path.GetFullPath(input);
  19.     }
  20. }

In this scenario, someone that’s debugging GetMyPath might want to see what’s being returned from the method.  Currently, they’re stuck assigning it to a local (or similar) inside the method (or putting the burden on all the callers to similarly assign it) in order to then see it, something like:

image

What some people may not realize is that you can set a breakpoint at the end of a method and it gets hit no matter the (normal) exit path.  For instance, for both of the callers in the above sample, they’ll hit such a breakpoint even though they exit via 2 different ‘return’ keywords.

image

image

Certainly there’s a school of thought (especially among old C++ developers) that you should create your return value at the top of your method and then return it at the bottom of your method (no multiple-return, no exception throwing, etc – inspired mostly by the various memory/resource handling patterns like needing to free allocated memory) but since the debugger obviously knows what the method is returning anyway, it would be awfully nice if it could show it to us Smile

Visual Studio (managed) debugger feature: magical local called $exception

One of the things you may have noticed when using the Visual Studio debugger (at least since 2005, if not sooner) is that if you have VS set to break on a CLR exception being thrown:

image

Then you get an extremely useful addition to your debug window Locals called $exception.  It’s not an actual local variable, of course, but a special addition from the VS debugger that lets you inspect and interact with the ‘active’ exception as if it were indeed a local variable:

Imagine we had this (broken) code as a console app:

Code Snippet
  1. using System;
  2. using System.IO;
  3. using System.Linq;
  4.  
  5. class Program
  6. {
  7.     static void Main(string[] args)
  8.     {
  9.         var path = args.FirstOrDefault();
  10.         var fullPath = Path.GetFullPath(path);
  11.         Console.WriteLine(fullPath);
  12.     }
  13. }

If we “run to cursor” (Ctrl+F10 by default) to the GetFullPath line, we get this at that point in time for our locals:

image

image

Now if you hit F5 (to run) or F10 (to step over) an exception gets thrown from that framework method and now we get a new entry in our Locals window called $exception:

image

NOTE: this special local is on the ‘first chance’ exception.  If you hit F10 to get it to a ‘second chance’ exception, you lose that special local and you’re back to a ‘normal’ exception (if you didn’t have break on exception thrown, this is what you would get to start with)

image