Latest: Genstatic, my first sip of coffee

Content with Style

Web Technique

Make sure firebug console debug doesn't break everything.

by Pascal Opitz on January 16 2009, 14:49

Maybe some of you have already had problems with leaving debug statements in JS code. A console.log() left in the deployed code can break the whole application, and it might only come up when someone without firebug is testing it at a later stage.

Very embarrassing indeed, and I recall a story where the whole development team had neglected to test without firebug, but a scheduled session of Acceptance Tests held at a different site was about to fail. Someone then had to rush there and managed to save the day by installing firebug on the test machine, so that they could get on with it. This taught me a valuable lesson about what can happen in an environment where there are many developers: Mistakes WILL happen!

People that do flash will know the trace() function, which gives you debug output, but can be turned off in the export settings, so that the compiler removes those calls from the generated SWF.
But javascript isn't a compiled language so there is no auto removal of debug specific code.
This is why we have to ensure that, even though code does still contain debug code, it shouldn't break. For javascript development this means that at least console.log and console.dir statements need to be dealt with. And yes, I agree: It shouldn't be in there in the first place. But we have to either make sure that calls to the console get removed or that the rest of the javascript application isn't affected when they're made.


Version control hooks

CVS, SVN or GIT offer hooks. I haven't tried this out properly, but I imagine a simple shell script could help. Like doing a grep for console.log and stopping the commit if there's anything in there that should only be debug code.
Of course with this method the downside would be that there would be no means to share the debugging code with other developers through the version control.

Build tools

A similar check/removal process could be done in the deployment stage. Using grep, sed or something similar on the project files to remove any debug related code would ensure that the javascript always gets deployed without debug code.

A mock object

We could provide a mock object, so that calls to the console wouldn't result in an error. This would ensure that the javascript doesn't fail, even though debug code is still in the code.

if(!window.console) {
  window.console = new function() {
    this.log = function(str) {};
    this.dir = function(str) {};

Wrapping the debug code

Another valid approach would be to wrap the calls to console.log, and provide error checking or try-catch inside the wrapper.
Of course this only works if all developers will use the wrapper instead of the firebug console object.

var Logger = new function() {
  this.log = function(str) {
    try {
    } catch(e) {
      // do nothing

Finally ...

Please keep in mind that what I've written is about keeping code from breaking the testing or staging environment. The truth is that, if there is anything that breaks the App in it's live deployment, then something is wrong with the testing process.

Related links


  • I have trouble calling the wrapper function and passing the str. Can you provide an example? Thank you

    by sna on February 11 2009, 23:25 - #

  • sna: if you'd use the Wrapper, instead of writing console.log('foo');, you'd use Logger.log('foo');. Hope this helps?

    by Pascal Opitz on February 13 2009, 16:46 - #

  • Simple but tricky problem at hand. Didn't realise that console.log() can break the whole app on live environment?!

    by Jason Grant on April 9 2009, 15:05 - #

  • very useful tips! thanks! I had the same similar problems in the past - reviewing a site with my client and on while on my side everything works perfectly, on his side the website fails completely - of course the reason were some console.log leftovers

    by jakub.chodorowicz on March 26 2010, 01:48 - #

  • Thank you for spelling this out. Some of this is really annoying since it only shows up later in the QA process.

    by Lacy on May 20 2010, 15:09 - #

Comments for this article are closed.