Conditional breakpoints are essential, just run as normal and it'll only break when your bizarre edge case is hit.
Debugger.Break and Debugger.Launch are like a breakpoint that gets hit even when you're not debugging, and prompts you to attach a debugger. ( Launch won't pause if you already have one attached, but especially useful when you want to attach to a start-up routine in an IIS hosted web-app. )
Debugger.Write writes to a different output stream, and like all Diagnostic.Debug statements, isn't even compiled into release builds, so there's zero chance of it ending up in prod.
These are essential tools for rapid debugging. Printing nonsense and hoping to spot it feels 20+ years out of date.
There are endless numbers of cases where you can still end up having to just resort to print debugging, even in C#. Race conditions are a great example.
Yawn. I’m all but certain that all the environments in these “print debugging fail” stories have debuggers. The fact that generation after generation of programmers fall into print debugging, despite there being “no reason” to do it in many contexts for…decades at this point, should tell you that you’re missing something, not that everyone is dumb except for you.
I'm not saying people are dumb, I'm saying we've failed to provide good dev UX for debugging, so that people find it easier to reach for print debugging than leverage their debugger.
Cool story bro. Let me tell the guys at work that we should just run .NET on our multi-core digital signal processors.
And we should also teach them not to get their delicate timing out of whack because they'll immediately stop dropping incoming samples if any of them gets interrupted by a debugger.
I don't think I'd be anywhere near as productive without:
Conditional breakpoints are essential, just run as normal and it'll only break when your bizarre edge case is hit.Debugger.Break and Debugger.Launch are like a breakpoint that gets hit even when you're not debugging, and prompts you to attach a debugger. ( Launch won't pause if you already have one attached, but especially useful when you want to attach to a start-up routine in an IIS hosted web-app. )
Debugger.Write writes to a different output stream, and like all Diagnostic.Debug statements, isn't even compiled into release builds, so there's zero chance of it ending up in prod.
These are essential tools for rapid debugging. Printing nonsense and hoping to spot it feels 20+ years out of date.