How to Use Breakpoints in Dev Tools- Part II

Last week, we started to take a look at the different kinds of breakpoints we can use in Dev Tools to debug JavaScript applications. We tried out some breakpoints- Line of Code, Conditional Line of Code, and DOM- using Dev Tools and a simple counter application. This week we’ll continue the adventure with three more breakpoints! If you’d like to follow along, go to last week’s post and follow the setup steps.

XHR Breakpoint

XHR stands for “XMLHttpRequest”. It’s a way to request data from a server without having to reload the webpage. You can create a breakpoint that will pause the code whenever an XHR request is made. To set this up, look in the right panel of the Dev Tools (making sure that you’re already on the Sources tab), and open the section called “XHR/fetch Breakpoints”. Click the plus (+) button in the section, and check the box that says “Any XHR or fetch”. (If you don’t see the checkbox and instead see an empty text box, click out of the box, and the checkbox should appear.)

We now have a breakpoint set up that will be executed whenever any call is made to the server. To trigger this in the Counter App, click the trash can icon for every counter so they are all deleted. Then click the blue recycle button. A server call will be initiated, and you’ll see the code pause on the breakpoint.
Don’t forget to click the Resume button and remove the breakpoint before the next section!

Event Listener Breakpoint

As you might imagine, the Event Listener breakpoint listens for a particular event, such as an animation, a keyboard entry, a mouse movement, and so on. We’ll set up a breakpoint to stop on a mouse click. In the rightmost panel of Dev Tools, open up the Event Listener Breakpoints section, and click on the arrow next to “Mouse” to open that section. Check the “click” checkbox. Now when you click on one of the buttons, you’ll see the application stop on the breakpoint.
Don’t forget to remove the breakpoint and click the Resume button before the next section!

Exception Breakpoint

This breakpoint can be set to stop whenever the code encounters an exception, and you can specify whether you want to pause on all exceptions, including caught exceptions, or just uncaught exceptions. To set this breakpoint, simply click on the blue pause button in the upper right corner of Dev Tools. Let’s also click the “Pause on caught exceptions” checkbox. To trigger an exception in the Counter app, click the trash can icon for all the counters, then click the blue recycle button. This triggers an exception on my Safari browser which pauses the code; looking at the code it seems to me that the exception is browser-specific, so your results may vary.
Don’t forget to remove the breakpoint and click the Resume button before the next section!

Stepping Through the Application

Breakpoints are great for pausing an application so you can see what state it’s in, and they are also good for stepping through the code. To learn how to step through the code, let’s go back and use a simple Line of Code breakpoint like we learned how to do in last week’s post. So make sure the “Sources” tab is selected at the top of the Dev Tools pane, find the src folder in the left section of Dev Tools, then open it up and click on the App.js file. Find line 16 in the file and click on it to add a breakpoint.

Click one of the plus (+) buttons in the application, and the breakpoint should stop on line 16. This time instead of clicking on the Resume button, click on the button next to it. This is the Step Over button, and it will send the code execution to the next line of code in App.js. Open up the Scope section and you can see the value of all the variables at this particular place in the code. As you continue to click on the Step Over button, you’ll be able to see the counter value change. Look in the counters: Array(4) section, and you’ll see that the specific counter you are using will go up in value.

Between this tutorial and last week’s, you now know six different ways to set a breakpoint in Dev Tools. I hope that you will find them useful when you are trying to diagnose tricky JavaScript bugs. Happy bug hunting!