.Net Tips – use DebuggerStepThrough attribute

When debugging your application, don’t you just get annoyed that pressing F11 keep taking you into the get method of the properties (auto-properties excluded!) passed into the method rather than the method you want to step into?

I use auto-properties wherever possible because they’re syntactically cleaner and have less maintenance overhead, and I have the same amount of control as with private fields because I can define the access privilege of the get and set methods independently.

The only time when I will still use a private field is when I want to expose a readonly variable so I can confine the assignment to the constructor but still allow other classes to access it. 99.9% of the time the get method will do a straight return so stepping through it have no benefit whatsoever, and it’s times like this the DebuggerStepThrough attribute can be a timesaver:

private int _myIntField;
public int MyIntProperty
{
    [DebuggerStepThrough]
    get { return _myIntField; }
}

This will stop the debugger from stepping into the get method when you try to step into a method like this:

DoSomething(obj.MyIntProperty);

You can, however, still put a break point against the get method when you do want to step through it without having to first take off the attribute and recompile though! :-D

Another situation where the DebuggerStepThrough attribute can save you time is when you use PostSharp-powered attributes.

When you’re debugging through some code which has try-catch logic encapsulated in a OnMethodInvocationAspect attribute like the RetryOnSqlDeadLockOrConnectionTimeOutExceptionAttribute I have here, you might be taken into attribute class when all you care about is what’s happening in the method the attribute is applied to.