CODEWITHSUNDEEP
visual-studiodebuggingvisual-studio-2015
J4N
J4N

Reputation: 20707

VS2015 throw caught exception within DebuggerStepTrough?

I just upgraded my VS2013, and the same code has a different behavior in debug mode.

In VS2013, I was having the debug breaking on exception I got.

Some of them that might happens and are handled were put in Try-catch block with a DebuggerStepTrough:

Example:

[DebuggerStepThrough]
private void DoSomething(){
    try{
        throw new InvalidOperationException();//Obviously in my case, it's not a throw exception here but a method
    }catch(InvalidOperationException){
        //log something & handling this case
    }
}


private void SomeEntryPoint(){
    DoSomething();//In VS2015 I got the debug breaking here. In VS2013 I don't
}

I was not having this behavior in VS2013. Is there a way to avoid it?

(I've the "Just My Code" enabled)

Upvotes: 4

Views: 346

Answers (1)

John
John

Reputation: 1379

You are correct, the behavior you described is a result of a new performance improvement that was introduced in the Visual Studio 2015. The new feature greatly reduces debugging overhead of processing clr exceptions thrown and caught within non-user modules (With Just My Code enabled).

Unfortunately, in an oversight, exceptions thrown and caught within functions with [DebuggerHidden], [DebuggerNonUserCode], and/or [DebuggerStepThrough] attributes are no longer treated as if they were thrown and caught within non-user code - the debugger essentially ignores those attributes with regard to exceptions in Visual Studio 2015 (Step filtering and Call stack filtering still work the same as they did in Visual Studio 2013).

The bad news is that there is no good way to restore the previous version's behavior for this scenario. There are 2 possible options:

  1. Target your application to use .net framework version < 4.0
  2. Refactor your code such that the functions/classes with those debugger attributes are in a different module and build that module optimized and/or without symbols.

The good news is that the Visual Studio debugger team has acknowledged the issue and will provide a workaround in the next update for Visual Studio 2015.

Update

The workaround for this issue is available in Visual Studio 2015 Update 2 and is detailed in the Using the DebuggerNonUserCode Attribute in Visual Studio 2015 blog post.

For those who just want to know what to do. Run the following in a command prompt:

reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1

Upvotes: 5

Related Questions