The debugger can also stop execution on breakpoints only when some conditions are met. We can apply expressions and hit count conditions to any breakpoint and remove them without resetting the breakpoint. We’ll revisit the Breakpoints Window to add expressions and hit count conditionals.
We can set as many break points as we want, 0:00 we can even have breakpoints that print to the output window like trace points. 0:03 Let's turn this trace point back into a breakpoint by right clicking on it and 0:07 clicking actions. 0:11 And click this continue execution checkbox here, and 0:14 this will cause the program to pause when it gets to the break point, but 0:17 our message will still be logged to the output window. 0:21 There are some other options here. 0:24 We can tell the debugger to hit a breakpoint only when a condition is met. 0:25 Let's add a breakpoint on line 40 that only causes the debugger to pause 0:30 when the number of songs is greater than 0. 0:34 Or right-click on the breakpoint and then click Conditions here. 0:37 Here we'll type songs.Count > 0. 0:40 Conditional breakpoints have a white plus and a red dot. 0:48 Now, this breakpoint will only get hit if the number of songs is greater than 0 0:53 when the program gets to line 40 of Program.cs. 0:57 Another handy condition is to only break when a variable or 1:00 the result of an expression changes. 1:04 We could change this so that the breakpoint is only hit 1:06 when the number of songs is different from the last time this line was executed. 1:09 So I'll change this to When changed. 1:14 And here we'll just look at songs.Count. 1:17 The first time the program gets to this line the break point won't get a hit. 1:21 But if we add another song and 1:26 then call the display song list method again, it will. 1:28 We can also have a breakpoint conditionally hit 1:32 based on the number of times the line of code has been executed. 1:34 This is very helpful when a bug only happens 1:38 after the program has been running for a while. 1:40 Here, inside the while loop up here, 1:43 we can change this trace point to a breakpoint. 1:44 Under conditions will change this conditional expression to hit count and 1:51 will change this to greater than or equal to. 1:56 And here we'll put 5. 1:59 So now this breakpoint will only get hit 2:03 if this line of code has been executed five or more times. 2:06 Notice there are some other options here. 2:10 The third type of condition is filter. 2:12 It's handy when debugging programs that have multiple threads of execution or 2:15 are in a distributed environment. 2:19 Notice that we can alter this file and 2:25 our breakpoints stay with the line of code that they are associated with. 2:27 This only works when editing the code from inside Visual Studio. 2:31 The breakpoints we set are saved when Visual Studio is closed so 2:35 the next time we open the project our breakpoints are still there. 2:39 However, if we alter the file from somewhere else or 2:42 merge the file with changes from a version control system. 2:44 You may find that your break points are no longer in the right place. 2:48 It does try to put them back in the correct line though. 2:51
You need to sign up for Treehouse in order to download course files.Sign up