What are the benefits of using System.Diagnostics.Debugger.Break() over Attach to Process?

Question

Using VS2008..To start debugging depending on my mood i'll either attach to process and hit break points that way or i'll place System.Diagnostics.Debugger.Break() in a relevant place in the code and start debugging when it breaks at that point.

The latter being necessary sometimes I find!

Not talking about F5 --> running in debug mode for a second..

System.Diagnostics.Debugger.Break();

Questions :

Q) I'm curious as to the minor differences between each option?

Q) What are the benefits and drawbacks of using each?

I'll start it off..

Debugger.Break() drawback = forgetting about Debugger.Break()'s and leaving them in there!

Debugger.Break() benefit = Start debugging exactly where you want without hitting other unecessary breakpoints that may still be in the code which would be hit if attached to process.

Pre-empt the haters

I'll just pre-empt the haters that will undoubtedly say if i'm using Debugger.Break() I'm not understanding the correct way of debugging.

I'm just trying to start a conversation here as I believe there are different ways of debugging depending on the circumstances.

-- Lee

Answer 1

I was once working on a plugin based app that did alot of things on startup. It would do the plugin discovery among many other things. I couldn't run it directly from VS, so F5 wasn't an option, but Attach to Debugger wasn't an option either, because many times I would need to debug all that stuff happening at startup. I would never be able to catch it in time with Attach to process. Therefore, I just set Debugger.Break() exactly where I want.

Another example; I was writing a cmdlt for Powershell. Those you don't run in VS you run them from the PS command line. They are usually quick little apps, and there's no way you'll catch them in time with Attach to Process.

Answer 2

In addition to BFree's answer, I've found Break to be occasionally useful when dealing with a poorly-designed legacy product. This particular product had a bad habit of swallowing or ignoring exceptions, and its logging mechanisms didn't (in fact, never did) work properly. It frequently violated many good practices that required the customer be "lucky" to get it to work at runtime. I started adding a quick blurb of code:

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

to specific spots that I was focusing on for debugging. This made it easier for me to see what was happening when and what was being violated without breaking the code when it was run by a customer. (My pipe dream is that this also, hopefully, clued in my somewhat less-clueful colleague.)

Yeah, I do know that this isn't an especially good practice and I would never do it in new code. But trust me, if you were spelunking through that code base, you'd have done something similar. ;)