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.
When we execute the code above, this what we should see. Notice the “paused in debugger” text 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
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!
debugger statement invokes any available debugging functionality, such as setting a breakpoint. If no debugging functionality is available, the statement has no effect.
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
c argument values. Hover over the function arguments and see for yourself.
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.
debugger indeed fires off and gives us access to inspect the
createPerson arguments. Can you tell what happens if we inspect the
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
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
Finally, press the resume button and fire off the 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
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 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.
Happy coding and stay awesome!