2

I am working with 3rd-party code that throws and catches a NullReferenceException as part of its ordinary, correct operation. I would like to be able to tell Visual Studio to ignore this instance (ie, ignore NullReferenceExceptions thrown from this .cs file + line number) but continue to break on other thrown NullReferenceExceptions.

Is this possible?

edit: By 3rd party code I mean source code that is part of the project, but that I don't own and won't be modifying. I can't use anything that relies on VS's definition of user code, for example, because this also counts as user code. The size of the project means that this detail is out of my control. For similar reasons I don't want to add [DebuggerHidden].

damian
  • 3,604
  • 1
  • 27
  • 46
  • 2
    If I'm reading you correctly you want to not break on the caught exception, but instead only want to break on the thrown and uncaught exception. You can specify that in Debug > Exceptions easily. – Joey Oct 20 '16 at 10:04
  • Or enable "just My Code" to ignore the exception in 3rd party code. – jessehouwing Oct 20 '16 at 10:05
  • 1
    All you can do is under Options->Debugging. Maybe it's enough to check "only activate my code". Keep in mind that exceptions are expensive in .Net. Should not be fired senseless. – Sebi Oct 20 '16 at 10:07
  • @Joey Hmm, how? I can turn on "Continue when unhandled in user code" (in VS2015) but that seems to be the opposite of what I want. – damian Oct 20 '16 at 11:04
  • If you have the source of the 3rd-party code, or can wrap the code in your own method, then maybe http://stackoverflow.com/questions/15275139/selectively-ignore-thrown-exceptions-in-c-sharp-code will help – sgmoore Oct 20 '16 at 11:11

2 Answers2

5

As others have mentioned, if an exception is truly caught and handled inside 3rd party code (where the debugger's definition of "3rd party code" is code that is in an assembly which is non-optimized AND we don't have .pdbs for), then to avoid the debugger from stopping on it, you simply need to go to Tools->Options->Debugging->General and enable "Just My Code".

If the code in question is not 3rd party code, you can add a DebuggerNonUserCode attribute to it, to control whether the debugger will break on an exception in the decorated method (again, assuming "Just My Code" is enabled).

In VS "15" Preview 5, you can actually disable breaking on an exception when it's thrown inside a specific module, but that's not available in VS2015.

Another option to workaround this quickly, is to use OzCode which has a ToolBar button for toggling "Break on All CLR Exceptions". This is a really quick way of enabling/disabling all exceptions, which you can toggle before you know the annoying NullReferenceException is about to occur. Break on all CLR exceptions

Disclaimer: I'm co-creator of the tool I just mentioned.

Omer Raviv
  • 11,409
  • 5
  • 43
  • 82
  • Thanks for the tool recommendation. Seems a brute-force approach, but maybe it's the way forward. Does it save and restore the state of the individual checkboxes when toggling exceptions, or does it simply turn *everything* on or off? – damian Oct 20 '16 at 11:34
  • @damian At the moment it simply turns `everything` on or off. We do have a user request in place to let you save "Presets" of exceptions and switch between them, and are hoping to add that in a future release. – Omer Raviv Oct 20 '16 at 11:44
  • Hmm, ok. 'Presets' sounds less useful than simply remembering what the state was when I click 'disable' and restoring it when I click 'enable' (Better yet - restoring it when debugging stops or VS exits). My enabled/disabled exception list is in constant flux and, unless I'm misunderstanding things, the idea of maintaining fixed 'presets' sounds like too much work. – damian Oct 21 '16 at 09:53
  • @damian That makes perfect sense, thanks a lot for feedback! – Omer Raviv Oct 21 '16 at 22:54
  • I read that `DebuggerNonUserCode` works only after executing the following command: `reg add HKCUSoftwareMicrosoftVisualStudio14.0_ConfigDebuggerEngine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1` This registry key will only work in Visual Studio 2015 Update 2 and beyond. Source of this information is a link from the above post: https://devblogs.microsoft.com/devops/using-the-debuggernonusercode-attribute-in-visual-studio-2015/ – Roland Pihlakas Aug 14 '23 at 15:03
1

If I understand you correctly, you don't want your code to stop being executed after a certain exception which occurs when you throw the exception. If you want to do this just put your try and catch block over that code and don't use the throw statement at all

         try
     { string strX  = textbox.Text
       int x = Convert.ToInt32(strX);
     }
    catch (FormatException){}
    ...rest of code

If you put a throw statement it would exit the block of code it is in

JohnChris
  • 1,360
  • 15
  • 29
  • Hmm, are you advocating silently swallowing the exception? That's a terrible idea :/ – damian Oct 21 '16 at 09:55
  • Well if I know a certain exception will occur- that doesn't cause any further errors, rather than write 10 lines of code to stop that exception occurring isn't it more efficient to just do that? -I'm new to coding so it just seemed logical – JohnChris Oct 31 '16 at 14:36
  • @damian, from further research "http://stackoverflow.com/questions/204814/is-there-any-valid-reason-to-ever-ignore-a-caught-exception" it is ok to some times do this, just have to be careful – JohnChris Oct 31 '16 at 14:41
  • Yeah, ok, you have a point. sorry for my knee-jerk reactions, I've just seen too many code that does a blanket catch-all where it's clear the developer hasn't actually thought about what that might mean. – damian Nov 01 '16 at 12:13