Let’s dive into errors in more depth: with the features built into the browser you use today, you can stop time, inspect values of variables as they change, and understand the call structure of your code.
The other thing you’ll need is Google Chrome. That’s because this is a specific, visual guide to one specific kind of developer tool. There are similar implementations in Firefox and other browsers: I would love if anyone wants to contribute a version for another browser: diversity is good.
The first step is opening the developer tools: this is a panel that usually sits below a webpage and gives you x-ray vision into its inner workings.
There are three different ways to open the developer tools: inspecting an element, clicking the toolbar menu, and hitting cmd-option-i (or ctrl-option-i on non-Macs)
Now that you’ve successfully opened your developer console, let’s move on to looking at a bug, in detail.
The basic parts of a bug are as follows: each gives you a different perspective on its cause and the potential solution
We’ve reviewed type in the last post.
The part where developer tools get really helpful is the filename, line number, and call stack: they’ll let you know where it happened, but also what happened before that, and what things were like when it happened.
So without further adieu,
The hierarchy of what function called which other function is the call stack: a listing of functions from closest to furthest from the currently-running line of code. The call stack is central to debugging because it reveals two fundamental principles:
code with calls to
which would trigger a popup with some value displayed, or just
if you wanted to check that some portion of code was running.
With the emergence of developer extensions
in most browsers, people switched to
which prints something in your console instead of popping up a window,
and if you call it with an object or element or some other kind of complex
type, it’ll pretty-print and let you inspect its properties.
Here’s the third wave: breakpoints. Read that as ‘take a break at these points’ instead of ‘make something broken’.
alert, breakpoints don’t need to be written into
your code. They’re also much better.
console.log logs only the things you choose: usually people will write
console.log(foo) or something similar and hope that that’s the important
part. Breakpoints, on the other hand, do something much different: they stop
time, letting you look at the values of any variable.
There are two ways of setting a breakpoint: the first, and most common, is to set them via your web browser.
Breakpoints are useful, and error details are too: let’s combine the two.
Chrome has a wonderful feature called ‘Break on Exceptions’ that combines the magic of error details and breakpoints - whenever an error occurs, it’ll stop time just like a breakpoint, with the same knowledge of its context.
I keep Break on Exceptions on whenever working on a project under development: it keeps me aware of any problems as soon as possible.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
I like to follow the Rule of Repair from The Basics of Unix Philosophy: it’s much better to fix problems sooner than later.
See how this is the combination of closely inspecting an error and stopping time with breakpoints? Notice that when you’re stopped on a breakpoint, all of the variables in scope at that time are accessible from what you type in the console.
Once you’re comfortable with the developer tools, some useful things to learn: