Set Breakpoints to Pause Execution3:31 with Guil Hernandez
The first step in debugging with VS Code is setting a breakpoint to pause your program at a specific line of code.
While the application is running in debug mode, you can visit any URL, and 0:00 the execution of the program doesn't pause, which doesn't allow you to inspect 0:03 the current state of the app and identify the problem. 0:07 That's because I haven't specified a place in the code where I want to pause debug or 0:10 execution. 0:14 This is the first step in debugging. 0:15 Pause your program at a specific line of code. 0:16 So I'll first identify where in the code I'd like to pause execution. 0:19 This might even be the same line where you'd place a console dot log statement, 0:22 for example. 0:26 I'll switch to the VS code file explorer by clicking the file symbol 0:26 in the left side bar, then click on the file app dot js to open it in the editor. 0:31 Again, the issue happens when you click o milo, for 0:36 example, or change the URL to anything. 0:39 The app displays blank reverse is eman. 0:42 The original string is missing from the response sent back. 0:46 So now, I'll diagnose and fix the problem using the debugger. 0:50 I'll go back into debug view by clicking the bug symbol in the sidebar. 0:54 And thinking about the problem, 0:58 the bug happens when you change the URL to reverse a string. 1:01 So on lines 35 through 42, a get URL handler takes 1:04 in the user string from the URL and reverses it. 1:10 So the URL handler seems like an appropriate place to pause the execution 1:14 of the application. 1:18 To pause the application, I'll use a break point. 1:20 You can set a break point on any line of executable code. 1:23 To create a break point, click on the far-left margin next to the line of code 1:27 where you want execution to pause. 1:31 I'm clicking line 37, or the first line of the handler function since 1:34 that's where the programming around the string reversal happens. 1:37 And the red field circle and the editor margin indicates that a break point is 1:41 set, and where the debugger or program should pause execution. 1:45 So let's revisit the app on local host port 3000, and 1:49 click on one of the examples. 1:52 And notice how the page It's stuck in a loading state. 1:54 Well, that's because the debugger has paused execution of the program. 1:58 The request from the express server is still open, and 2:02 the response hasn't been sent back yet. 2:05 In the VS code editor, 2:07 you'll see the line of code highlighted where the break point is. 2:08 And the highlighted line is how you know that the debugger has 2:12 paused the application. 2:15 So now, I can take advantage of several panels to aid in debugging. 2:16 For example, the call stack panel shows the full list of functions called in order 2:20 to get to the break point. 2:25 It helps you keep track of what's currently being executed in the program. 2:26 This panel can be quite noisy, and is used rarely when you don't understand when or 2:30 why something is being called. 2:35 So I'll keep the call stack details mostly hidden by closing the panel for 2:37 the remainder of this workshop. 2:41 You can add multiple breakpoints while debugging. 2:43 For example, I'll add another breakpoint online 42. 2:45 When I click the Continue button in the debug-actions toolbar, 2:50 the debugger moves forward in the program, and stops at the next breakpoint. 2:54 You can also immediately see where all your breakpoints are, 2:59 here in the breakpoints panel. 3:02 And you can toggle them on and off with the checkboxes. 3:04 A grey circle in the editor margin indicates a disabled breakpoint. 3:08 To remove a breakpoint from your source code, just click on it. 3:13 So now, I'll click the Continue button to finish running my program. 3:17 Coming up in the next video, you will learn how to inspect and 3:23 debug variables using the variables panel and debug actions toolbar. 3:26
You need to sign up for Treehouse in order to download course files.Sign up