Question

The title may be a little confusing so I’ll explain. Say you had this call chain…

public DoWork(index) >> private DoWorkHelper(index) >> private CheckIndex(index)

Now if you call DoWork, it traverses the calls down to CheckIndex, adding each deeper call to the call stack.

Now if someone calls DoWork with a bad value for index, it throws the exception all the way down at CheckIndex, and currently, that’s where the debugger breaks. You then have to walk back up the call stack to see the real offender was that someone passed bad data to DoWork.

Now back in the VB6 days, you could simply decorate DoWorkHelper and CheckIndex with an attribute to say ‘If any exception is thrown inside me, don’t highlight me, but rather my caller because they were the ones that passed me bad crap!’ So in this case, the code would break inside DoWork with the call to DoWorkHeper highlighted.

There was also a setting to disable this so for deeper debugging purposes it could still be thrown at CheckIndex, the level where it actually occurred, but half the time, breaking down there tells you nothing because you don’t know how you got there without walking back up the call stack.

Think of it a way to decorate your code to say when you hit an exception, auto-traverse the call stack to the point where the bad value actually tells you something useful.

Note this is similar to ‘Break On All Exceptions’ except you’re handling this via decoration. Plus, you’re not setting to break on a specific type of exception (e.g. all null reference exceptions, etc.) but rather a specific method! (or more accurately, the one that called the decorated method.)

So does C# or .NET in general have this?

---

Update

While I credit Dark Falcon for the answer since he directed me there, I’ve added a more detailed explanation about what all the attributes mean, and in what context. Check it out below.

Answer 1

Please see the Just My Code option. You need to decorate DoWorkHelper with DebuggerHiddenAttribute or DebuggerNonUserCodeAttribute.