Properties and debugging

As I am sure everyone reading this article knows, the CLR support ‘properties’, which is a way of making function calls look like a variable read or write. These have some problems for debuggers, mostly because in order to evaluate a property, the debugger has to execute code inside the debuggee.

The biggest problem is that side effects of properties can cause different behavior inside the debuggee (application being debugged). This is more likely to be a problem if the user’s code implements properties (as apposed to code inside the .NET Framework), since you are probably using the debugger to figure out why your code doesn’t work. However, by debugging the code, the debugger can execute properties, which can cause the bug to go away. To make matters worse, even if you set a breakpoint on the property, you won’t hit it. If you think about it for a while, this makes sense. If you had ‘this’ expanded in the watch window, we would infinitely go into break mode.

Another problem is that property evaluation is slow. Setting up the debuggee to run code is much slower then reading a bit of memory out of the debuggee. Complex properties can make the debugger look hung.

A third problem is that the debuggee may not be in a safe place to execute code. If some other thread has stopped after taking an important lock, then evaluating the property will just hang. Once the code is hung, it may be difficult or impossible to restore the state of the debuggee. This problem is going to be more important going forward because we will by trying to run less of the debugger inside the debuggee.

One last problem is that properties often expose the same value as a member variable. For my code, I would prefer to see ‘m_Foo’ then ‘Foo’ in the watch window. Having both is redundant.

Property evaluation can be turned of by disabling the option ‘Tools->Options->Debugging->General->Allow property evaluation in variables windows’. However, this is kind of a sledge hammer approach. I would like to see an option where I don’t see properties in my own code, and I don’t see private member variables of types that aren’t my code. This way, if I am looking at a .NET Framework type, it looks like the interface I use to program to. If I look at my own type, I don’t see all those redundant properties. Maybe someday we will do this. What do you think?

One last note: I would like to make a recommendation to stop running complex code inside a property. I have heard of code which does network I/O or spins up threads inside of properties. This code is a bad idea in general, but it makes debugging your code significantly more difficult. In Whidbey, you will be able to add an attribute to these properties to tell them to not evaluate. That’s a start.

Comments (9)

  1. moo says:

    i use _ prefixing on private fields and the usual style on the rest unless Im matching a specific problem area with well known notations.

    I would like to see properties be set by passing into an arguemnt in a method.

    I know ref doesnt work as its basically a method in disguise but how about a new way of doing this either by a new keyword or transparently. Surely its not that hard to call the set_ method as part of the arguemnt like setting an out or ref. It would feel more a natural way to use a property set.

    We can use get_ propertit accessors in an argument, theyre just called before the actual method call is run, so why not run the set_ AFTER the method call?

    Yeah and having the intellisense popup window for members in the debugger watch window would be nice.

  2. Dmitriy Zaslavskiy says:

    As I mentioned in Andy Pennell’s blog, it would be really nice to have private on/off, internal on/off, properties on/off. It would also be nice to have defaults based on dll(s). This way in my code I would like to see privates and not properties, but in 3rd party libraries there is (almost) no point in seeing privates.

  3. Gregg Miskelly says:

    I agree with you. Unfortunitely, I don’t think we will have time for Whidbey.

  4. Louis Parks says:

    I understood that there were debugging attributes that could be set on members to determine how (or if) they displayed in the VS Whidbey debugger. Did I misunderstand something?

  5. moo says:

    There is [Browsable(true | false)] for the designer visibility, I never seen one for the debugger. The debugger should show everything, if one cant handle that dont use the debugger and get a new job.

  6. moo says:

    Thats what the "Watch" window is for, or tooltip values, watch what you want to watch, nobody forces you to expand everything in the Auto window. Sheesh, by the time we finish satisfying these wannabie software designers, we will be coding Visual Big Birg Development Picture Book. Develope by numbers, just add colour.

  7. Gregg Miskelly says:

    For Whidbey, there is a feature to control how things show up under the debugger.

  8. moo says:

    Great, now I can HIDE my bugs!