How to Find Bugs in Your JavaScript Code With the Debugger

What exactly is the debugger statement in JavaScript?

Indrek Lasn
Sep 7, 2019 · 5 min read
Photo by John Schnobrich on Unsplash

Did you know that JavaScript has a debugger built-in? The debugger is useful when it comes to finding bugs and stepping over nested callbacks, promises, etc. The debugger statement works on both client- and server-side rendered JavaScript code.



The debugger statement lets us stop code execution and inspect any variables, values, etc. Essentially, it acts as the return key and stops the function from executing.

Debugging JavaScript

When we execute the code above, this what we should see. Notice the “paused in debugger” text and resume and loop-over buttons on right. On the left panel, we see the “sources” tab and our debugThis function with the values we passed in. If you hover over variables a and b — you see their values.

It would be an understatement to say this is a handy tool when we have much more complex stuff happening and we need to inspect what went wrong. More complex applications might fetch data from ten different data sources, but one of them might fail. Why and how? debugger to the rescue!

To resume as normal, press the “resume” button.

The debugger statement invokes any available debugging functionality, such as setting a breakpoint. If no debugging functionality is available, the statement has no effect.

Multiple Debuggers

Debuggers truly shine when we have more than one debugger statement and lots of callbacks or promises. Take the following example, where we have a closure function. We grab the outer function’s a value and pass it to the inner function:

The debugger gives us a flexible way to check all values of the function. Inside the closure, we can inspect the a, b, andc argument values. Hover over the function arguments and see for yourself.

Debugger inside a closure

Now that we’re getting the hang of the debugger, let’s go for a more complex example. First, we check whether we pass the name argument to the createPerson function. If not, we stop all code execution and shout a warning to the console. If there is a name, create a person object with the arguments passed to it.

Note: If the object shorthand syntax is unfamiliar to you, I’d suggest checking out this article.

Once we call the createPerson function with its given arguments, the debugger should pop up. Let’s see what it tells us.

Firing off our first debugger

The first debugger indeed fires off and gives us access to inspect the createPerson arguments. Can you tell what happens if we inspect the person object?

person object is undefined

Undefined? Why is the person undefined? Simple — because we haven’t executed that part of our code yet. We stopped our code execution at the first line of the function. We don’t have scope access to the person object since it doesn’t exist.

If we press the blue resume button, our second debugger fires off, this time inside the hasName function.

The second debugger fires off

Now we’re inside the hasName function — this function quickly checks if there’s a name passed to the person function or not. It doesn’t make much sense to have it in a separate function, since we could check the single property inside the createPerson — but for debugger demo purposes it’s a useful display of how to apply the debugger practically. Our person object is still undefined since we’re executing the hasName function, and haven’t reached the part where we create the person object.

Finally, press the resume button and fire off the third debugger:

Firing off our third debugger

Voila! We should be able to see all the variable and object values since effectively, our code has reached its execution. What happens if we don’t pass a name to the createPerson function?

What happens if we don’t pass a name to our createPerson function

Clearly, there’s a warning in plain sight about how we forgot to pass a name to the function. A person can’t have no name—unless a person is No One (at least in “Game of Thrones”).

Next time, before you’re about to write console.log try to find excuses to use the debugger instead. On paper, you can set up your web bundler, such as webpack or parcel to remove the debugger statements in production by default. The debugger also works inside a Node environment.

If you want to use the debugger with Node, check out this article I wrote earlier. I go in-depth on how you can debug the server-side JavaScript code.


If we’re given useful tools to make our lives easier, we ought to use them and use them often. The debugger is a handy tool to have in your toolbox when the right time comes.

If you enjoyed this article and want to learn more about how you can efficiently debug your JavaScript code, check out the article below.

If you’re new to JavaScript and want to learn the language, I recommend starting with reading books combined with building things. Start with the “A Smarter Way to Learn JavaScript” book and here’s a list of fun apps to build.

Happy coding and stay awesome!

Better Programming

Advice for programmers.

Indrek Lasn

Written by

JS, Swift, C++ Indie Dev. Oh, and startups. Connect with me on Twitter @

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade