Debug Better: 7 breakpoints in Chrome DevTools

7 min readJun 4, 2019

When I was a trainee, I was given a probationary project. It was challenging for me as it was my first time working with a dual server. I love using ajax at that time for my form submission, and using console.log() in order to view the response is normal for me that I actually use it frequently, and being forgetful is normal to me as well. (Hehe!) I actually committed my code and forget to remove a bunch of console.log() . It was found by my senior when he conducted a code review (it is a process in our company where your senior developer reviews your code for further enhancement). I was thankful for two things at that time; first, it happened on the local and not on the production, because it would be really bad; second, is that my senior conducts the code review thoroughly that he found all of it and made me remove those.

Most developers have already worked with JavaScript and I am not an exception to that. As a developer, your one way of debugging your codes in JavaScript is through console.log(), but if you use this frequently on debugging your code you will realize that you’re not really doing it efficiently. All, or most of us have been saved by console.log(), I admit that I spent most of my time using that.

One of the scary thing that can happen is if someone leaves it in his/her source code then commits it, there is also a chance that your code will contain a bunch of console.log(), just like what happened to me, and one example of that, is this console below.

You have to run your code, test your code, debug it, and then run it again, if ever there’s still a bug you have to go through it again, and the cycle goes on and on until you get the result you want and get the job done. This is the cycle that we are used to, it gets the job done, yes, but not really efficiently and this takes up most of our development time. It is almost impossible to spot a developer that did not go through this cycle.

Quite messy, right? Do you believe we can actually lessen this? Us developers don’t have to deal with this kind of mess anymore, or at least we can lessen it. Browser’s Developer Tools or DevTools already have a way to fix this problem, through the use of breakpoints. Breakpoints can help you debug your codes efficiently and effectively. Breakpoints can lessen the usage of displaying the output of our code through console.log(). No need to worry if you forgot to delete any of it during deployment. If we want to debug our codes efficiently, a breakpoint is one of the tools that can answer to our needs. In fact, there are actually seven types of breakpoints to use depending on our needs;

7 Types of Breakpoints

1. Line of Code Breakpoints

When you know the exact position of code that you need to debug, use Line of Code breakpoints.

Blue Icon

On the Sources tab of your browser DevTools, go to the line of code that you want to investigate. Click on the number line column of the code and then a blue icon will appear on it.

*This is the breakpoint that I use most of the time when debugging is not complicated. It is also actually pretty easy to use.

2. Conditional Line of Code Breakpoints

When there’s an exact position of code that you need to investigate, but you want to pause only when some other condition is true, you can use Conditional Line of Code breakpoint.

On the Sources tab of your browser DevTools, go to the line of code that you want to investigate. Right click on the number line column of the code and then select Add Conditional Breakpoints. A dialog will show up underneath, enter your condition and then press enter to activate the breakpoint. An orange icon will appear on it instead of the blue one.

*This one is almost the same with Line of Code Breakpoint

3. DOM Breakpoints

Use a DOM breakpoint if you want to pause on the code that changes a DOM node or its children
On the Elements tab, go to the line that you want to set a breakpoint on. Right-click the element, then over Break on, select between Subtree Modifications, Attribute Modifications or Node Removal.

4. XHR Breakpoints

If you want to break the process when the request URL of an XHR, contains a specified string. On the line of code where the XHR calls send(), DevTools pauses.

On the Sources tab, click Add breakpoint on the XHR breakpoints pane. Then, enter the string you want to break on and then press Enter to confirm. When the string is present anywhere in XHR’s request URL, DevTools will pause.

*XHR Breakpoint is pretty handy when you use Ajax or Axios frequently

5. Event Listener Breakpoints

This is used when the developer wants to pause on the event listener code that runs after an event is fired. There are other events or categories of events.

Expand the Event Listener Breakpoints pane on the Sources tab, it shows a list of event categories. Check one of the categories, pause on any event from that category or a specific event

*My favorite breakpoint, I actually enjoy playing with event handlers using this breakpoint.

6. Exception Breakpoints

You can also pause your codes in a line of code that is throwing an exception (caught/uncaught)

Click Pause On Exceptions on the Sources tab. You will see that it is enabled when it turned blue. You can also check the Pause On Caught Exceptions if you want to pause on it also.

7. Function Breakpoints

When you want to pause the code on a certain function, include debugger; after your function. You need to make sure that the target function is in scope, otherwise, it will throw a “ReferenceError”.

DevTools Control Buttons

1. Resume Script Execution

If this button was clicked while enabled, the source code would resume executing normally.

2. Step Over Next Function Call

This executes the function but does not step into it.

3. Step Into Next Function Call

This button will go inside asynchronous functions and step onto the next line. It works the same way with Step button, the only difference is this button go through on an asynchronous function.

4. Step Out Of Current Function

The rest of the function will be executed then proceed with the next line of code

5. Step

This button will step inside every function it needs to check further, line by line.

6. Deactivate Breakpoints

Deactivate all existing breakpoints but this button does not remove them.

7. Pause On Exceptions

Pause on exceptions that exist in the source code

Debugging can take up a lot of time. Run your code, debug it, then test it again and so on and so forth. During the development process, this takes up a lot of time and breakpoints minimizes the work for us because you can actually debug your JavaScript codes on the browser already. It may take some time to get used to browser DevTools (trust me)especially if you are so used to using console.log(). Rest assured that it is is also effective in JavaScript debugging and very easy to use. As this is only a brief explanation of Breakpoints, I’ve included some references for you to understand more. Feel free to correct me if there are some information that are misleading.

References:

How To Pause Your Code With Breakpoints In Chrome DevTools