Debugging Attributes
Have you ever been debugging code and examined the properties of an object? You get both the public properties and the private member variables! Why is that? Can this be avoided?
This seems to violate the principles of encapsulation. It also complicates the process of examining the contents of an object at run time. You don’t really want to have to look at all of the private member variables which by definition should be irrelevant to the task of debugging.
Fortunately the violations to encapsulation pose limited risk. Even though the debugger will reveal hidden member variables, you still cannot access them in your code.
The confusing part is when you view an object’s detail and you have to filter through potentially twice as many variables as there are properties.
How do you remove this potential confusion in the objects that you create? Enter the System.Diagnostics.DebugBrowsable attribute:
Add a DebuggerBrowsable attribute to private member variables.
[System.Diagnostics.DebuggerBrowsable (System.Diagnostics.DebuggerBrowsableState.Never)]
Now these variables will not show up when you do a Quick Watch. This will clean out the entries from the Quick Watch that you did not intend to be visible.
Another debugging frustration is stepping into methods or properties that you are no longer interested in.
Before c# 3.0 introduced implied properties, business entities could be particularly frustrating since they often included several very simple properties that you never had any need to step into.
I would often try to step into a method and have to step into several properties’ get accessors to pass their values as parameters.
Not only is this annoying, it is also potentially confusing and time consuming as the debug bounces around in irrelevant code as you are trying to figure out why an errant method is not behaving as you expect.
If only there was a way to instruct the debuger to ignore certain pieces of code …
Turns out that there is!
[System.Diagnostics.DebuggerHidden] Causes the debugger to completely ignore the method.
[System.Diagnostics.DebuggerStepThrough] The debugger will not step into the method but will honor breakpoints in the method.
[System.Diagnostics.DebuggerNonUserCode] This attribute is similar to combining the first two attributes. This is intended for generated code or designer code.
Since these are attributes, you have to pay attention to the AttributeUsageAttribute.
DebuggerHidden and DebuggerNonUserCode can be tied to properties. DebuggerStepThrough cannot. It can be applied to methods though. This means that it would have to be applied to the get and set individually for a property and not to the property as a whole.
The DebuggerStepThrough attribute causes some problems for CodeDom since there is no way to associate attributes with the individual methods that make up a property. Use the DebuggerNonUserCodeAttribute instead.