5 JavaScript Debugging Tips To Save Your Sanity

If you’re debugging your way through your website using console.log or just looking to discover some features you might not know about, these tips are set to save you a bit of precious time. Admittedly it’s not the juiciest of topics but let’s face it, we spend a lot of time “developing” in the debugging environment so let’s make the most of the tools we have.

Debugger statement

Seeing a debugger statement in your code (poor-mans breakpoint)

The first step to moving away from console/alert statements, shove a debugger; in your code. Now when you have your web inspector open (it will only invoke when the web inspector is open), you’ll be sent into a debugging environment, able to explore all the things.

This is useful even for the seasoned developer as you may be working with a minified file that has no counterpart sourcemap. In which case you’re usually pretty buggered with options to debug.

Make sure you remove it before it goes live :)

Using the console in the debugger

See all the properties available at this point in time

Once in your debugging breakpoint, you can either switch to the console tab or press escape to bring up a contextual console panel. From here you can inspect the state of your variables, execute functions and get autocompletion of object properties. Especially useful when you’re working with external code and you want to reverse-engineer a JS API.

Conditional breakpoints

When you’ve set a conditional breakpoint the breakpoint turns orange

Now you’re mastering the debugging environment it’s time to take it to the next level of awesome; conditional breakpoints. These will only kick in during deeper investigations such as iterating over arrays or keeping tabs on a heavily mutated variable in a async context.

This can be a massive time saver as you no longer need to step over n number of iterations until you hit the state you care about. To activate this; right click on the line number you care about, click on “Add Conditional Breakpoint” and add a condition like you would inside an if statement.

Async traces

Stepping through the asynchronous call stack

Tracing through call stacks that involve AJAX requests or digest cycles in Angular can be confusing as hell if you don’t have async tracebacks. Fortunately, Chrome web inspector has this beauty that lets you see what called what and with what closure state at that point of time. N.B. It’s really useful here to name your anonymous functions so it’s not just a list of “(anonymous function)” lines.

Pause on exceptions

Enable all the pause options (but remember to turn them off when done)

Now, this one is probably the least sexy of an unsexy subject but it’s pretty damn useful. If you’re banging your head against a wall because it’s making no sense that your code’s not throwing an error and is failing silently, this could be your saving grace. Click on the little pause icon in the debugging controls and also the pause on caught exceptions checkbox. This will result in all sorts of breakpoints being hit from the nitty gritty of jQuery trying to initiate Sizzle to Angular doing all kinds of witchcraft but eventually it’ll bubble up to your code and you’ll see that elusive exception waiting for you to inspect the state and make sense of it all.

See the exception before it happens

I hope you found at least some of this useful and leave a comment if you have any of your own debugging tips not covered here.