Does Debugger.Break have any side effects?

Question

System.Diagnostics.Debugger.Break(); // this DB call has not been mocked

I'd like to place these in code at the site of I/O calls to let unit test developers know when they haven't properly mocked out the call, but I don't want to create new problems.

1. Does calling Debugger.Break() have any impact when compiled as Release?

2. Does it have any impact when executing a Debug build but not debugging?

Answer 1

Unfortunately for your use-case, it does.

To address your concerns:

1. Debugger.Break will work for any build configuration. Debug, Release, or anything else.

Tim Schmelter had a good suggestion. If you want to limit Debugger.Break to only Debug builds then you can use Conditional Compilation .

#if DEBUG
    Debugger.Break();
#endif

2. Debugger.Break will have side effects, even if the debugger isn't attached.

If there's no debugger attached then it'll either try to attach a debugger, or send a message to the Windows Error Reporting (WER) subsystem depending on what version of the .Net Framework you're targeting.

If no debugger is attached, users are asked if they want to attach a debugger.

...

Starting with .NET Framework 4, the runtime no longer exercises tight control of launching the debugger for the Break method, but instead reports an error to the Windows Error Reporting (WER) subsystem.

https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.debugger.break?view=netframework-4.7.2#remarks

Answer 2

As the comments and @AndyJ's answer explain, your program will crash if no debugger is attached to the process.

What you may want is to check if the debugger is attached before calling Debug.Break at runtime. There is an API property for that, System.Diagnostics.Debugger.IsAttached