Can .NET source code hard-code a debugging breakpoint?

Question

I'm looking for a way in .NET (2.0, C# in particular) for source code to trigger a debugging break as if a breakpoint was set at that point, without having to remember to set a specific breakpoint there in the debugger, and without interfering with production runtime.

Our code needs to swallow exceptions in production so we don't disrupt a client application that links to us, but I'm trying to set it up so that such errors will pop up to be analyzed if it happens to be running in a debugger, and otherwise will be safely ignored.

My attempt to use Debug.Assert(false) has been less than ideal, and I assume that Debug.Fail() would behave the same way. It should theoretically have no effect in production, and it does successfully stop when debugging, but by design there is (as far as I can tell) no way to continue execution if you want to ignore that error, like you could with an actual breakpoint, and like it would do in production where we swallow the error. It also apparently breaks evaluation of variable state because the debugger actually stops down in native system code and not in ours, so it's debugging help is limited. (Maybe I'm missing some way of getting back into things to look at the variables and so on where it happened. ???)

I was hoping for something like Debug.Break(), but it doesn't seem to exist (unless maybe in a later version of .NET?), and no other Debug methods seem applicable, either.

Answer 1

System.Diagnostics.Debugger.Break?

Answer 2

I ran into a situation once where this didn't work

System.Diagnostics.Debugger.Break();

but this did

System.Diagnostics.Debugger.Launch();

Answer 3

You probably are after something like this:

if(System.Diagnostics.Debugger.IsAttached)
  System.Diagnostics.Debugger.Break();

Of course that will still get compiled in a Release build. If you want it to behave more like the Debug object where the code simply doesn't exist in a Release build, then you could do something like this:

[Conditional("DEBUG")]
void DebugBreak()
{
  if(System.Diagnostics.Debugger.IsAttached)
    System.Diagnostics.Debugger.Break();
}

Then add a call to it in your code.

Answer 4

How about just configuring Visual Studio to pop up with the debugger even if you swallow it?

Do this:

• Go to Debug->Exceptions...
• Find the right exception, or add it if it's your own
• Check the "Thrown" checkbox for the exception

This will stop Visual Studio on the location that exception is thrown, not just if it isn't handled.

You can see more information here.

Answer 5

Ahhh, thanks, shahkalpesh. System.Diagnostics.Debugger.Break() is a good start! That's what I was missing, under Debugger instead of Debug. It looks like that will interrupt and ask to attach a debugger, which I might want to avoid. But it looks like...

    if (Debugger.IsAttached)
        Debugger.Break();

...might do what I'm looking for, as ctacke suggested. Debugger.Launch() might work for slightly different sitations, where you want a debugger if there wasn't one already.

Answer 6

A nice trick I found is putting Debugger.Break() in the ctor of your Exception.