Geek Answers Handbook

In C # (or .NET in general) can you mask the level of the call stack where the exception was thrown through the attributes?

The name may be a little confusing, so I will explain. Say you had this call chain ...

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

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

Now, if someone calls DoWork with a bad value for index , it throws an exception to the end in CheckIndex and now, when the debugger breaks. Then you need to go back to the call stack to see that the real culprit is that someone passed bad data to DoWork .

Now, in the days of VB6, you can simply decorate DoWorkHelper and CheckIndex attribute to say: "If any exception is thrown at me, do not select me, but rather my caller, because they were the ones, it ruined me! Therefore, this In this case, the code will be broken inside DoWork with a dedicated call to DoWorkHeper .

There was also a parameter to disable this, so for deeper debugging purposes it can still be reset to CheckIndex , the level where it actually happened, but for half the time, crashing there, says nothing, because you don’t know how did you get there without raising a stop call.

Think about this to decorate your code, to say when you click on the exception, automatically go to the call stack to the point where a really bad value tells you something useful.

Note that this is similar to “Break On All Exceptions”, except that you process it through a decoration. In addition, you do not set gaps for a specific type of exception (for example, all null reference exceptions, etc.), but rather a specific method! (more precisely, the one called the decorated method.)

So, does C # or .NET have this at all?

Update

While I am responsible for the Dark Falcon for the answer, since it directed me there, I have added a more detailed explanation of what all attributes mean and in what context. Check it out below.

+4
source share
2 answers

See only my code . You need to decorate DoWorkHelper DebuggerHiddenAttribute or DebuggerNonUserCodeAttribute .

+4
source

Just adding what I found to explain better so people don’t have to look elsewhere ...

Three attributes are associated with this: DebuggerHidden , DebuggerStepThrough and DebuggerNonUserCode .

Here are the rules:

If Just My Code not checked:

  • DebuggerNonUserCode
    This is mostly ignored. Breakpoints, steps, and exceptions all work just as if this attribute were not.

  • DebuggerStepThrough
    This applies to breakpoints and will break into exceptions if they occur, but you cannot manually step on the blocks marked with this attribute.

  • DebuggerHidden
    This prevents you from entering these blocks, ignores breakpoints, and any thrown exceptions are handled in the calling method, and not where they actually occur.

If Just My Code marked

  • All three attributes behave the same as if you used DebuggerHidden above.

There is another DebuggerStepperBoundary attribute, which is pretty cool. Here is an excerpt from MSDN:

Use the DebuggerStepperBoundaryAttribute parameter to avoid moving from code to running code. For example, in Visual Studio 2005, encountering the DebuggerStepperBoundaryAttribute attribute when executing code using the F10 key (or the Step-by-Step command) has the same effect as pressing the F5 key or the Start Debugging command.

Hope this clarifies the situation! Of course he did for me!

+2
source

More articles:


All Articles