Debugging is one of those skills at the heart of a programmer’s business.
Sometimes we try our best, but the program does not work properly, for example it crashes, it is just slow, or it prints out wrong information.
What do you do when a program you’ve written doesn’t behave as expected ?
You start to debug it.
Determine where the error might be
The first step is always to look at what is going on and try to determine where the problem is coming from. Is this a problem in the environment? Is it a problem with the contribution you made to the program? Is this a one-time crash due to excessive memory usage? Or does this happen every time you run it ?
These are all key information to start moving in the right direction when determining a problem.
Once you have an idea of where the error is coming from, you can start checking that specific part of the code.
Read the code
The easiest way to debug, at least in terms of tooling, is to read the code you’ve written. Aloud. There is something magical about hearing our own voice that doesn’t happen when you read in silence.
Often times I have found problems this way.
Using the console
Using the console
If reading the code doesn’t tell you anything, the next logical step is to start adding a few lines in your code that can enlighten you.
console.log (and his cool friends).
Consider this line:
Somehow the result is not calculated correctly, so you can start by adding
alert(b)before calculating the result, and the browser will open two warning panels when executing the code.
It works fine if what you are switching to
alert()is a string or a number. As soon as you have a painting or an object, things start to get too complicated to
alert(), and you can use the console API . Starting with
Chrome development tools
Chrome development tools
The result of the
The tool is very powerful and allows you to print complex objects or tables and you can inspect all properties of them.
The debugger is the most powerful tool of browser development tools, and it can be found in the Sources panel:
The upper part of the screen displays the file browser.
You can select any file and inspect it on the right. This is very important for setting breakpoints, as we will see later.
The lower part is the actual debugger.
At this point, execution is halted and you can inspect everything about your running program.
You can check the values of the variables and resume the execution of the program line by line.
But first, what is a breakpoint? In its simple form, a breakpoint is a
breakpoint instruction inserted in your code. When the browser meets it, it stops.
This is a good option during development. Another option is to open the file in the Sources panel and click on the number of the line to which you want to add a breakpoint:
Clicking the breakpoint again will remove it.
After you add a breakpoint, you can reload the page and the code will stop at that execution point when it finds the breakpoint.
When you add the breakpoint, you can see in the Breakpoints panel that
form.js in line
7 has the breakpoint. There you can see all your breakpoints and temporarily deactivate them.
There are also other types of breakpoints:
- XHR / recover breakpoints : triggered when a network request is sent
- DOM breakpoints : triggered when a DOM element changes
- Event listener breakpoints : Triggered when an event occurs, such as a mouse click
In this example, I set a breakpoint in an event listener, so I had to submit a form to trigger the it:
Now all the variables that are in scope are printed, along with their respective values. You can modify these variables by double-clicking on them.
Look at variables and expressions
Right at the Reach panel there is the Watch panel.
He has a
+button that you can use to add any expression. For example by adding
name will print the
name value of the variable, in the example
Flavio. You can add
name.toUpperCase()and he will print
Now all scripts are stopped since the breakpoint stopped execution.
There is a set of buttons above the « Paused on breakpoint » banner that allows you to change this state.
The first is in blue. Click on it to resume normal script execution.
The second button is step over , and it resumes execution until the next line, then stops again.
The following button performs an enter in operation: enters the function being executed, letting you enter into its details.
Exit is the opposite: returns to the external function calling it.
These are the primary ways to control the flow while debugging.
From this devtools screen, you can edit any script, also while the script is interrupted in execution. Just edit the file and hit cmd-S on Mac or ctrl-S on Windows / Linux.
Of course, changes aren’t kept on disk unless you work locally and set up workspaces in Developer Tools, a more advanced topic.
Inspect the call stack
A lot of times you work with libraries that you don’t want to « go into », you trust them, and you don’t want to see their code in the call stack, for example. As in the case above for
validator.min.js, which I use for email validation.
Hope it does a good job, so I can right click on it in the call stack and hit Blackbox Script . From there it is impossible to get into that script code and you are just working on your own application code.
Use the browser developer tools to debug Node.js
Since Node.js is built on the same engine of Chrome, v8 , you can link 2 and use Chrome DevTools to inspect the execution of Node.js applications.
Open your Terminal and run
Then, in Chrome, type this URL:
Click on the dedicated Open DevTools for Node link next to the Node target, and you will have access to Node.js in the DevTools browser: