Using 'debugger' to help in javascript debugging | Hacker News Reader

Using 'debugger' to help in javascript debugging

blog.filepicker.io

16 pointsbrettcvz17 comments

Pro Tip: ‘debugger’ statements cannot be disabled at runtime

In Chrome, you can just press the "Deactivate Breakpoints" button in the DevTools and `debugger` statements won't do anything anymore. Closing the DevTools also prevents `debugger` statements from breaking execution.

In Firebug (Firefox) you can selectively disable 'debugger' statements. You can even disable them only if a condition is true.

You can also trigger the debugger only if certain conditions exist. This is helpful if you are trying to fix a bug in a code branch that is hit very often, but the bug only happens under certain conditions.

  if (this.foo()) debugger

Chrome also supports conditional breakpoints[1].

1. https://developers.google.com/chrome-developer-tools/docs/sc...

  It’s better in many cases than manually setting a breakpoint in the inspector.

Why does the author believe that statement is true? I'd much rather manually set breakpoints in the inspector than have to alter code.

edit: formatting

I prefer debugger; in 2 scenarios:

1) I have the code open in my text editor but not in the inspector. Rather than open it in the inspector and search around for where I need the breakpoint I can just pop it in the code and the inspector will open up where I need it.

2) Working with single page apps where breakpoints sometimes have a hard time persisting after a file changes. Nothing more frustrating than making a change and losing your breakpoints.

Just to preempt certain comments, I realize that many people have known this for ages, but there are many who have not, and to them this might just make their day.

Also, "+new Date" is neat

Since ecmascript 5, Date.now() is the standard way of doing this. Generally speaking, I'd prefer to do that (with shims for older browsers) than do the equivalent of creating a new Date object and calling .valueOf on it (which is what +new Date does).

Actually the firebug add-on for Firefox does allow you to disable the 'debugger' statement at runtime, making it safe to insert anywhere in your code.

Other than that, good tip.

Chrome Dev Tools also lets you ignore breakpoints, but I hope you're not suggesting to ship code with debugger statements?

I don't it'll be much of a concern in a few years, though we're not there yet. Currently, Chrome will just gloss over any debugger statements unless the dev tools is open; if others happen to follow suit, then leaving a debugger statement in won't have any side-effects.

Still a really bad practice, IMO

I know, but leaving rogue debuggers after you're done using them is not good practice.

Sorry if I gave that impression! What I meant to refer to was that you can insert them somewhere in a loop and then disable it once the loops ran a few times rather than having to press continue (potentially) several hundred times.

Ah, yes. That is useful

Maybe I'm being cynical, but I find it hard to believe that any "very talented front-end engineer" wouldn't know about the debugger.

This sort of post should be a "pro-tip" on coderwall.com

Reply on news.ycombinator.com