DEV Community

Olivia Pomeroy
Olivia Pomeroy

Posted on • Updated on

How to Debug in JavaScript

How To Debug In JavaScript

Unlike the systems we use- we are human! Which means we are going to make mistakes, and probably a lot of them. There is nothing worse than writing a giant chunk of code, just to realize it isn't working the way you hoped. Is it a syntax error? Did you forget to call the function? Thankfully there are some tools we can use to help us figure out the issue so we can continue creating some really cool stuff! In this post we're going to understand what debugging is and look into two options on how to debug in JavaScript.

The browser I'll be using is Chrome, but most other browsers have a similar process.

What is Debugging?

Debugging is a tool developers use in order to go through their code and fix any errors that may arise. It can be done by examining a line of code to ensure it runs the way we'd like, or by forcing the code to pause at a certain line, letting us inspect the set block of code.

Using Console.log()

Console.log() is one method of debugging we can use. This is part of the browser's developer console panel. To access the developer console, you can right click on the browser page, click inspect, and go to the console panel. (You can also click on the view tab at the top of your computer, click developer, and then developer tools). Console.log() can be written in the browser's developer tools itself, or wherever your line of code is written. To use it in the browser's developer tools, follow along below:
Say we had a variable set as an array:
const flowers = ['Orchids', 'Tulips', 'Roses'

We can check that we declared it correctly by console logging console.log(flowers); in our console. We should get an output of (3) ['Orchids', 'Tulips', 'Roses']

Image description

That's what we got! We can see that our variable 'flowers' is now assigned to that array, so we can use it in future codes without worry.

For more complex functions, we can implement our console.log() within the function and verify it logs to our console. Such as, if we had the following variable and event listener:
const btn = document.querySelector("#button")
btn.addEventListner("click", function() {
console.log ("I was clicked");

Once we invoke that function, when we click the button we should see in our console:
I was clicked

Image description

This was important to us because it confirmed that we properly set a variable, grabbed it, and assigned an event listener to it. Now that we know the button works, we can continue on writing what we would actually like it to render to the DOM.

Essentially, console.log() will do just that- log what we choose in the console!

Using Debugger Keyword

The debugger keyword is...(wait for it)... "debugger;". Like console logging, debugger can be done in the browser's developer tools(under the source panel), or inputted into your line of code. The JavaScript code will run until it hits the debugger keyword, which acts like a breakpoint. Debugger allows us to pause the code, which means we also can resume the execution with the provided buttons (check out this linkfor a more descriptive walk through of how to use the buttons in developer's tools sources. Follow along in the example below to see how to implement debugger in your line of code.
This is a basic function in our index.js to make the concept a bit easier:

function math (){
 let x = 2 * 5
 let y = 3 / 8
 let z = 9 - 9  
 return z + y;
console.log (math())

Enter fullscreen mode Exit fullscreen mode

(A debugger within a debugger! The reason for putting console.log is to just to show you where the debugger keyword stops the code, as shown later in this section)

If we open our index.html in our browser, and navigate to our developer tool's source panel, when we run this code we should see this:

Image description

The code stopped executing where we placed the debugger, so that we could inspect everything was running properly above it. We see the variables are returning the proper data so we can resume our debugger. (It's important to note that because it has stopped at the debugger and only able to read what was declared before it. Console.log(math()) value is not appearing in our console because it comes after the debugger)

Image description

Once we resume our execution of code, it will then give us the desired output.

Image description

To implement debugger in our developer's tools, we can choose where we would like to place it by using the pane in the right-hand side (or bottom depending on how wide your browser is) of the source panel. The YouTube Channel Google Chrome Developers does a great job of showing you where you can place the debugger.

When to use Console.log vs Debugger Keyword

So which one is better? Well, that depends on what you already know about your code. It's nice using console.log() when you have a better understanding of your code and exactly where to place it. If you want to make sure your "click" event listener is working, console.log a message and then click on the button! I personally think console.log() is great for when you are checking as you go, practicing frequently.

The debugger keyword is good to use when you get an error message and aren't really sure where the error could be. Instead of going back and console logging multiple things, it would be best to put in the debugger keyword to scan through a general area, and pause to take a look at each line of code. The debugger keyword as a debugging tool can be faster and more efficient if used in this way, and allows us to work with the code more than console logging does.

Now Go Debug Like an Exterminator

In short, we went over that debugging is a tool we can use to help us find our errors and fix them. As a developer, a lot of our time is spent debugging and we need ways to make this process more efficient. We learned we can use our console.log() or debugging keyword to help us out, and the different situations we may use one over the other. It's important we debug as we go, in order to help ourselves out in the long run. Bugs will happen (and that's okay!), just remember to take it slow, work through the errors, and you'll be back to creating in no time!

Top comments (0)