JavaScript console.log / trace等的策略

Question

I am writing a rather large JavaScript software. I need to trace calls, log events, debug actions, while maintain performance and portability across browsers.

Webkit and Firebug both offer console object with methods like trace(), log(), error(), warning(), etc. They are great, but what do I do when the browser is IE or Opera?

Imagine having a big application, you surely want to see all initializations it is doing, events it is making, etc., thus I make it log those. However, if I just log those, the logging will not work in browsers that do not have console registered in the DOM. I could create a wrapper object:

MyNamespace.Console = {};
MyNamespace.Console.log = function(value) {
 if (console!==undefined) {
  console.log(value);
 }
 else {
  // What should I do to log events on other browsers?
 }
}

The above makes so no problems occur on IE / Opera, but how do I log with IE (one really needs logging with IE!).

Also, if I plant logs everywhere in my application, does it slow me down when it is being run on a production environment? Should I have a switch DEBUG on/off and a simple check before logging that if DEBUG===true, then log?

What about systems like Closure Compiler, can you make them to remove logging?

What if there is an error while running on production environment and logging has not happened, how do you debug/find the problem? And in fact, do you ever send JavaScript error logs to you (developer), to make sure your clients are not having problems? How does that work out?

I appreciate any feedback/comments on debugging/logging with JavaScript, this is my first time writing a huge JavaScript application, and frankly, I am not sure what should I do about this... debugging and logging in JavaScript seems a bit unfinished.

Answer 1

I wouldn't recommend having the application report log data back to the developer—at least not without disclosing this to users/clients first.

It would be a safer practice to log errors/events/debugging data to an array initially as Anurag suggests, and then periodically send the log data to the web server where it can be stored locally and cycled. Then if the client is having problems , they can pull up the logs themselves for debugging and, either, send it to you manually, or explicitly tell the application to transfer the logs to you, the developer.

Logging to the console is generally used during development anyway. And a debug flag should be used for that so that it won't be turned on at all times.

Answer 2

You can just add all log messages to an array or object. An object could look like:

var logMessages = {
    'log': [],
    'debug': [],
    'error': [],
    ...
};

where the array represents messages logged for that level, ordered chronologically or using some other criteria.

You could simply define identical interfaces for browsers that lack a console to the ones that do have it. For example,

if(!window.console) {
    var console = {};

    console.log = function(msg) {
        ..
    };

    console.debug = function(msg) {
        ..
    };

    ..
}

The list of messages could be synced with up a server, which I am guessing may only be necessary for errors, and possibly warnings. To catch all errors on the page, setup a callback on window :

window.onerror = function() {
    ..
};

and inside the callback, report to server. This may not play very well with Opera. See javascript-global-error-handling

Answer 3

Do a google search for accord redbird console.

Redbird allows remote logging directly from any standards compliant browser using pure JavaScript. It does not impact your web service and it should work on Safari, Firefox, Chrome, Opera, MSIE, Smartphones, etc.

Redbird comes in handy for debugging code that works fine in one browser but does something different in another. A common way to log and aggregate messages across different browsers helps in identifying differences.

Using a DEBUG flag as you suggested is a good idea. Lots of debugging messages can slow things down in a production environment. Another option for production environment is to replace the logging function with a null function, ie a function that does not do anything. This avoids having lots of if DEBUG statements in the code.