In C# is there any statement equivalent to DebugBreak()? I want to invoke the debugger when ever a particular condition is met.
Add a comment
|
4 Answers
You can use the Break method of the Debugger class, in the System.Diagnostics namespace:
Debugger.Break();
Now, there's also a different way you can add conditional breakpoints, without mucking about with adding code to your project.
This of course only works when already running your program through the debugger
What you can do is first add a regular breakpoint at the location where you want your debugger to stop, then right-click the red dot for the breakpoint:
and then edit the condition to fit your needs:
This will then be symbolized with a small + inside your breakpoint dot:
answered Jan 19, 2011 at 9:51
Lasse V. Karlsen
394k107 gold badges651 silver badges845 bronze badges
5 Comments
Default Writer
You can't declare a breakpoint on a complex conditions IN THAT WAY(using the conditional clause).
CodesInChaos
The nice thing about Debugger.Break is that it works even if no debugger is attached yet.
Lasse V. Karlsen
@Artur There's a limit to the complexity, yes, I just added it to complete the answer. The correct answer to the particular question is still
Debugger.Break();Default Writer
I suppose that Debugger.Launch() shoud not be allowed from production code, so I need #if statement, Debbuger.Launch() also completely breaks security and can lead to unexpected results. On the other side Debug.Assert throws an exception on a codition met (allowin to break under VS IDE), skips by the compiler completely on a release build, so this is a good alternative, not bad one.
AntiHeadshot
Also, you should keep in mind that Conditional Breakpoints slow down your application significantly. Debugging a loop and only breaking in some cases can take ages.
Concerning the other answers, I prefer using Debugger.Launch().
If the application is not already running in a debugger, Launch() will call up the debugger dialog allowing you to attach Visual Studio (or another debugger) to the process. However, if you are already debugging, it will sail right past the Debugger.Launch() call. Break(), on the other hand, will act as a breakpoint - breaking every time it hits that point (and invoking the debugger dialog if the process has not been attached).
Be VERY careful not to leave either statement in your code. Sending code with Debugger calls out to production can halt your application or create very hard to track down errors (bad experience last month).
1 Comment
AbrahamJP
Joe, thanks for detailing the difference between Debug.Launch() and Debug.Break()
System.Diagnostics.Debugger.Break();
//Lauches the JIT debug window
System.Diagnostics.Debugger.Launch();
This is particularly useful when debugging a service as you get the Just In Time debugger window and can then select the visual studio window to debug the service in.
4 Comments
Richard
If you only want it to fire when a debugger is already attached,
Debugger.IsAttached can be checked.
WraithNath
@Richard - for which line of code? the debugger does not need to be attached for Debugger.Launch as this then shows the window to give the opportunity to attach a debugger
Richard
the first (obviously).
if (Debugger.IsAttached) { Debugger.Break(); } is a useful pattern to have a permanent break point (not dependent on debugger saving state), I usually include it in the last chance exception handler within #if DEBUG.WraithNath
@Richard - thanks, to be honest i have only ever used debugger.launch so i didnt know about debugger.attached. Thanks for the info! +1
Maybe Debugger.Break
System.Diagnostics.Debugger.Break();
