You are not able to single out an exception thrown at a specific place in your code. You are however able to disable exeptions of a specific type.

If your own code throws the exception in question, i would make it a custom exception, derived from whatever fits, and then disable debug breaking on this derived type.

Disabling system exeptions as NullReferenceException will affect the entire system, which of course isnt desirable during development.

Note that there is two kinds of break-behaviors for exceptions:

• Thrown: If selected, breaks as soon as a exception of this type is thrown
• User-unhandled: If selected, breaks only if the exception, of this type, is not handled by a try/catch.

You could remove the check in 'Thrown' for the NullReferenceException which will give you the benefit of not breaking each time your system passes the line in question in your code, but still breaking if you have some unhandled NullReference expection occuring in other parts of the system.

If I recall correctly you can use a DebuggerStepThrough attribute on the method that contains the code you don't want exception to fire. I suppose you can isolate the code that fires the annoying exception in a method and decorate it with the attribute.

DebuggerHidden is your friend!

The common language runtime attaches no semantics to this attribute. It is provided for use by source code debuggers. For example, the Visual Studio 2005 debugger does not stop in a method marked with this attribute and does not allow a breakpoint to be set in the method. Other debugger attributes recognized by the Visual Studio 2005 debugger are the DebuggerNonUserCodeAttribute and the DebuggerStepThroughAttribute.

Tested on VS2010 and works great.

While DebuggerStepThrough seems to also work for some specific debugger versions, DebuggerHidden seems to work for a wider range of situations based on the comments to both answers.

Note that both options do not currently work with iterator block methods or for async/await methods. This could be fixed in a later update of Visual Studio.

Note that it does not work with combination of .NET Core + Rider, you can vote the issue.

DebuggerStepThrough is the one to be used to prevent the debugger to break in a method where there is a try/catch.

But it only works if you didn't uncheck the option "Enable Just My Code (Managed Only)" in the General settings of the Visual Studio's Debugging Options (menu Tools/Options, node Debugging/General)...

More info about that attribute on http://abhijitjana.net/2010/09/22/tips-on-debugging-using-debuggerstepthrough-attribute/

DebuggerHidden will simply prevent the Debugger to display the method where the exception is thrown. Instead, it will show the first method on the stack which is not marked with that attribute...

The attributes specified in the other answers (and other ones such as DebuggerNonUserCode attribute) no longer work in the same way by default in Visual Studio 2015. The debugger will break on exceptions in methods market with those attributes, unlike in older versions of VS. To turn off the performance enhancement which changed their behaviour you need to change a registry setting:

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

More information can be found on the visual studio blog.

(This should probably be a comment on the top answer but I don't have enough rep)

So I found a solution that works in VS 2019, it is a bit more complicated than I would like but for my use case it was necessary to solve this problem.

Instructions

First move the code that is causing the issue to its own function so you are not suppressing exceptions in surrounding code, and mark it with the DebuggerStepThrough attribute (or DebuggerHidden works too).

[DebuggerStepThrough]
public void ExceptionThrowingFunction()
{
//.. Code that throws exception here
}

Then call it like this

OutsourceException(ExceptionThrowingFunction);

Then take either a separate project (module) that either you don't care about suppressing all exceptions in, or that is specifically created for this purpose. It is important that this is a separate project so that your main project can still break on this exception type. In my case I already had a small util project called SharedFunctions so I put it there. The code is pretty stable and does not need debugging most of the time.

In a class called ExceptionUtils I added the following functions:

public static T OutsourceException<T>(Func<T> func)
{
T result = default;
try
{
result = func.Invoke();
}
catch { }
return result;
}


public static T OutsourceException<T, Y>(Func<T, Y> func, Y arg)
{
T result = default;
try
{
result = func.Invoke(arg);
}
catch { }
return result;
}


public static void OutsourceException<T>(Action<T> action, T arg)
{
try
{
action.Invoke(arg);
}
catch { }
}

You may need to add more of these, these cover just the basic cases where you have 0-1 arguments in your function.

Finally, when you run the code, it will still break on the exception in the Outsource function with a message like this: If you check the bottom checkbox (in this example 'SharedFunctions.dll') it will add a rule that the exception should be ignored if thrown from that assembly. Once this is checked the exception should be suppressed. All other exceptions in the main assembly of this type will still break as normal.

What is happening here?

Due to the changes in VS 2015 that broke the [DebuggerHidden] and similar attributes (see the blog post linked in another answer here) the attributes now pass the exception to the calling class and the debugger simply breaks there. The if we move the calling class into another assembly we can suppress the exception using the exception conditions system.

Why not just fix the exception?

Some exceptions can't be removed from the code completely, for example when you try to access Package.Current in a UWP application. It will always throw an exception in the debugger, and this can only be resolved by microsoft. Another solution in this case is to just surround it with #if !DEBUG but there are other cases where this is not practical.