9

Setup:

1) MSVS 2015, Option -> Debugger -> "Just My Code" is checked.

2) This sample code placed within some class and called during startup:

    static bool TestIgnoreException()
    {
        Exception ex;
        return TrySomething(out ex);
    }

    [DebuggerNonUserCode] // Prevent exceptions from stopping the debugger within this method. 
    static bool TrySomething(out Exception exOut)
    {
        try
        {
            if (Environment. MachineName.Length != -1)
                throw new Exception("ThrewIt.");

            exOut = null;
            return true;
        }
        catch (Exception ex)
        {
            exOut = ex;
            return false;
        }
    }

3) Launch Debugger

Expected result is that TestIgnoreException() runs silently and returns false.

Actual result is the debugger stops in TestIgnoreException() even though there should be no exception being processed at that scope.

enter image description here

4) Also re-tried using [DebuggerHidden] instead, same results.

Motivation:

The motivation is for cases where some API that is out of your control does not provide a "Try" method and instead only indicates failure by using exceptions.

One of numerous such examples is .NET TcpClient.Connect(host, port). Say a program always tests some connections during startup, the debugger should not stop on this particular section of code each time.

Using the standard "break when thrown" exceptions checkboxes is is not good because it works globally by type. It cannot be configured to work locally. Also other developers who check out the code should automatically skip the exception as well.

crokusek
  • 5,345
  • 3
  • 43
  • 61
  • Just untick the "Break when this exception type is thrown" checkbox. Problem solved, no need for any of this either. – Hans Passant Sep 08 '16 at 04:36
  • 1
    Then it would stop on every exception of that type which is not desirable. Also, another motivation is that other developers who check out the code should not witness the exception (just like what happens in lower level net code raises). Also, something is broken here it seems with the [Debug*] attributes it seems, no? – crokusek Sep 08 '16 at 16:59
  • 1
    No, you have that backwards. Learn how the Debug > Windows > Exception Settings dialog works, press F1 to get started. Your assumption that attributes lets you change this behavior is just wrong. – Hans Passant Sep 08 '16 at 17:01
  • Please respond to the 2 points in my comment. That feature does not meet either. Also the [Debug*] attribute has let me change the behavior to a degree (exception not stopped within decorated method) so your second sentence is false. – crokusek Sep 08 '16 at 17:04
  • You are getting a bit too agitated. Your beef is with Microsoft, not with me, I'm just telling you how it works. Use their uservoice site to provide feedback. – Hans Passant Sep 08 '16 at 17:16
  • I'm like 0 for 5 on msconnect.com. And I'm 50/50 here. Thank you for at least implying that this problem could be real. I may post this to msconnect anyway after gathering some info/workaround. – crokusek Sep 08 '16 at 17:25
  • You have it set to break on every exception. The attributes won't do anything to stop the debugger when you have it configured this way. – Matthew Whited Sep 08 '16 at 23:45

1 Answers1

8

Mystery solved. It is indeed a known issue that is new to MSVS 2015 because of added exception handling optimizations.

https://blogs.msdn.microsoft.com/visualstudioalm/2016/02/12/using-the-debuggernonusercode-attribute-in-visual-studio-2015/#

There is a workaround posted on that link to disable the optimizations and enable the old behavior. Hopefully they will eventually be able to revive the support for this including the optimizations.

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

Related question:

Don't stop debugger at THAT exception when it's thrown and caught

Community
  • 1
  • 1
crokusek
  • 5,345
  • 3
  • 43
  • 61
  • Glad to know that you have resolved this issue, please mark it as the answer:) – Jack Zhai Sep 11 '16 at 03:09
  • This workaround did not resolved it in my tries. It just make the bad debuging performance worser! When the "*Use managed compability mode*" option is enabled this issue seems to be resolved. However it disables the ability of **edit and continue** while debugging. So it is useless for my style of coding. http://stackoverflow.com/questions/41964808/visual-studio-2015-debugger-stops-for-a-handled-exception-of-a-debuggerhidden-fu?noredirect=1#comment72490364_41964808 – Koray Mar 09 '17 at 05:02
  • 1
    Any idea how to fix this in VS2017? The registry doesn't seem to work anymore, since it's, well, for VS2015. The suggestion from @Koray unfortunately did not work for me either. – Livven Sep 20 '18 at 09:20
  • What a shame. I did notice In 2017, when an exception occurs, an option was added to ignore that type of exception only _within_ the assembly it occurred in. That nice but still doesn't allow developers to share the ignores via code check in and its not method specific. – crokusek Sep 20 '18 at 16:44