Debugging7:28 with Jeremy McLain
Learn how to use the Visual Studio debugger.
Visual Studio is constantly compiling and analyzing your code while you're coding. 0:00 This helps catch errors, warnings, and other problems early. 0:05 Inevitably, I still encounter situations where there are errors when I go to build. 0:08 Maybe I renamed a variable that was being referenced in another file and 0:13 I didn't remember to change it in the other file. 0:17 Visual Studio can't catch everything all the time. 0:19 The point is, you will encounter compiler and other build errors and 0:22 Visual Studio can help you to deal with them. 0:26 Let's introduce a compiler error to this code. 0:28 I'll remove a semicolon from this line and then click start. 0:30 The code compiles and I get this message. 0:34 There are build errors. 0:38 Would you like to continue and run the last successful build? 0:39 I almost never answer yes to this. 0:42 In fact, I would check this box to never show this message again. 0:44 I'll click No here and 0:49 what I see now in the bottom of the screen is the Error List pane. 0:51 This lists all the errors and warnings that the build system encountered. 0:57 I can double click on any of these lines and 1:01 it will bring me directly to the line that it thinks is causing the problem. 1:03 The first thing I'm looking for are the squiggly lines I mentioned before. 1:08 I see them here at the end of the line where I'm missing the semicolon. 1:13 If I had to pick three killer features of Visual Studio, 1:17 I'd have to say the editor with IntelliSense, 1:20 code navigation which I touched very briefly on with search, and the debugger. 1:23 The interactive debugging provided by Visual Studios sets the standard by which 1:29 all other IDEs are compared to. 1:34 I'll show you the very basics of debugging. 1:36 In general, the main capability of any debugger is the ability to pause 1:39 the execution of the code in order to get a closer look at what is happening. 1:43 Code can be executed at a rate of millions of lines per second, so 1:47 being able to pause it at any time and inspect the values of variables, or 1:51 step through the code during execution one line at a time, 1:56 is a huge benefit when tracking down bugs. 2:00 So how do you pause execution? 2:03 The most common way is to set a break point. 2:05 You set a break point by first finding the line of code that you wanna stop at and 2:08 then clicking on this gray bar on the left side. 2:12 The program will pause right before executing that line of code. 2:15 Let's try it out. 2:19 Let me add a couple of lines of code here first to call the split name method and 2:20 write some output to the console. 2:24 Okay, that's better. 2:44 Let's say I wanna know what the value of the input variable is, 2:46 when it's passed to the SplitName method. 2:48 I'll set a break point here on the first line, and run the program. 2:51 The program ran for a bit and is now stopped here where I set the break point. 3:02 You can see the yellow arrow on the red break point dot, and 3:08 the whole line is highlighted in yellow. 3:11 As you can see, a lot of things changed in the user interface. 3:15 These changes happened because Visual Studio is now in debug mode. 3:18 First the toolbars changed, and there are a couple of new toolbars added. 3:24 Also, a few new panes appeared on the screen. 3:28 This diagnostic tools pane is a new feature in Visual Studio 2015. 3:31 It allows us to see CPU and 3:36 memory performance information about each line of code while we're debugging. 3:38 Debug time profiling is a big topic that I'm not gonna go into for 3:43 this workshop, so I'm gonna go ahead and close this pane for now. 3:47 These other panes are commonly used during debugging. 3:51 The call stack pane shows how the program got to this line. 3:54 We can see that this method was called from line 19 in main. 3:58 The autos pane shoes all of the variables that are in scope. 4:03 And we're reference leading up to the point in the execution. 4:07 Here we can see that the value of input is Jeremy McLain. 4:11 The locals pane shows all of the variables that are in scope at the location 4:15 of the break point. 4:19 This is often a larger set of variables than what is shows in the Autos pane. 4:20 The Autos and Locals panes are automatically populated by the debugger. 4:24 And they can fill up fast. 4:29 If you wanna keep just a few variables in view, 4:31 you can make your own pane of Watch variables by using a Watch pane. 4:34 This helps when you're really just concerned about one or two variables. 4:38 Just right click on the variable and click on add watch. 4:42 The variable appears in the watch one pane. 4:45 The watch pane can also be used to evaluate expressions. 4:48 For instance, if I want to see what input.split will return, 4:52 I can select the expression. 4:57 Right click and click add watch. 4:58 The statement appears in the watch window. 5:02 As you can see, the result of this expression is a type string array. 5:04 To see the contents of the object, 5:08 just click on the little triangle to the left here. 5:10 This works for any complex types, and 5:13 you can drill into objects as far as you'd like. 5:15 Once you've paused the execution using a brake point ,you may wanna step 5:18 through the code line by line. 5:22 To show off this feature, let's restart the debugger and 5:24 stop at the beginning of the program. 5:27 To do that, I'm going to set a break point here on the first line of main and 5:29 click start. 5:32 The debugger breaks execution at the break point. 5:40 Now, we can step through the code. 5:43 There are three buttons here on the toolbar that are used to step 5:45 through the code. 5:47 Hovering over the button displays what it does, and its keyboard shortcut. 5:49 Step into executes the currently highlighted line of code, and 5:53 moves to the next line. 5:57 If the currently highlighted line contains a method call, 5:58 it will move to the first line inside that method. 6:02 But there's a caveat. 6:05 By default the debug will only attempt to step through the programmer's code. 6:06 It won't go into .net or other external assemblies. 6:11 Of course, you can change this behavior with a setting. 6:15 As you can see, the debugger steps over the call to console.right but 6:19 it will step into the split name method. 6:23 If I click step into once again, it brings us to the very end of the method and 6:25 stops on the closing curly brace. 6:30 It's often useful to pause at the closing curly brace 6:32 to inspect what the method will return. 6:35 If I press step into one more time, 6:38 it brings us back to the line with the method column. 6:41 I can keep pressing step into until it gets to the end and the program exits. 6:44 Or I can click the Stop button at any time to stop the program and the debugger. 6:50 The Step Over button works just like the Step Into button. 6:59 Except it was always step over methods without going into them. 7:02 This is very useful because often times, we wanna step 7:07 through a section of code without stepping into every method called by the code. 7:10 Finally, the Step Out button will cause the debugger to run 7:16 through the end of the currently executed method, or code block. 7:19 It will then pause on the next line that's executed after the method returns or 7:23 the code block exits. 7:27
You need to sign up for Treehouse in order to download course files.Sign up