.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.

Subscribe to my newsletter and get new contents delivered straight to your inbox :-)