Using 'debugger' to help in javascript debugging(blog.filepicker.io)
blog.filepicker.io
Using 'debugger' to help in javascript debugging
http://blog.filepicker.io/post/43421141403/using-debugger-to-help-in-javascript-debugging
7 comments
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()) debuggerChrome also supports conditional breakpoints[1].
1. https://developers.google.com/chrome-developer-tools/docs/sc...
1. https://developers.google.com/chrome-developer-tools/docs/sc...
It’s better in many cases than manually setting a breakpoint in the inspector.
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.
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
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.
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?
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
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.
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
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.