28

I'm doing some debugging where I really want to have the "break when exception is thrown" option turned on. There's a third party assembly I rely on that regularly throws exceptions. Some of them, like SynchronizationLockException I can turn off via Debug -> Exceptions menu.

The problem is they also have some custom exception types. Is there anyway to turn those off?

Jeff B
  • 8,572
  • 17
  • 61
  • 140

3 Answers3

39

In the Debug > Exceptions dialog, click Add, select Common Language Runtime exceptions, and enter the full name (not the assembly-qualified name) of the exception. Then uncheck the Thrown checkbox for this exception.

Thomas Levesque
  • 286,951
  • 70
  • 623
  • 758
  • 10
    There's also the option in VS2015 of simply waiting until the exception is hit and unchecking the 'Break when this exception type is thrown' box in the exception helper window. – jnm2 Feb 16 '16 at 13:35
  • 1
    Is there a way to share this accross people of the project? – J4N Oct 04 '17 at 09:05
  • @J4N no, it's a per user setting. Technically, you could share it by committing the .vs folder / .suo file to the repo, but I wouldn't recommend it, as developers would always be overwriting each other's preferences. – Thomas Levesque Oct 04 '17 at 12:03
7

In Visual Studio 2019, when the exception occurs, there will be an information dialog.

Just un-check "Break when this exception type is user-unhandled".

exception dialog

Andrew
  • 18,680
  • 13
  • 103
  • 118
4

I think that you can try to uncheck this option <All Common Language Runtime Exceptions not in this list>:

Uncheck

In this case, most .NET Framework built-in exceptions will break but not those custom exception types which do not appear in the list.

Should you find some more exception types that you wish to break, you can right click on the Common Language Runtime Exceptions and then add more types to break:

Add types to break

victor6510
  • 1,191
  • 8
  • 14
  • Thanks for the try, but it doesn't do the trick. Not surprising as turning off all CLR exceptions didn't do it for me either. – William Jockusch Oct 06 '21 at 16:52
  • Should I read the question correctly the requirement should be "By default break on most exceptions but I want to efficiently disable a set of custom exceptions instead of disabling one by one." With the above configuration it will break on common .NET built-in exceptions but continue for custom exceptions. Or do I read the question wrong? – victor6510 Oct 07 '21 at 02:39
  • Woah, looks like I read the question wrong. OK then. The further problem however is that when I uncheck that option, it still breaks on custom exceptions, at least for me. – William Jockusch Oct 07 '21 at 13:14
  • Interesting, today VS *is* respecting that checkbox for me. Yesterday it did not. I did upgrade from 16.10.something to 16.11.4. I don't know if that's the reason. – William Jockusch Oct 07 '21 at 13:22