views:

1872

answers:

8

I'd like to create a "universal" debug logging function that inspects the JS namespace for well-known logging libraries.

For example, currently it supports Firebug's console.log:

var console = window['console'];
if (console && console.log) {
  console.log(message);
}

Obviously, this only works in Firefox if Firebug is installed/enabled (it'll also work on other browsers with Firebug Lite). Basically, I will be providing a JS library which I don't know what environment it will be pulled into, and I'd like to be able to figure out if there is a way to report debug output to the user.

So, perhaps jQuery provides something - I'd check that jQuery is present and use it. Or maybe there are well-known IE plugins that work that I can sniff for. But it has to be a fairly well-established and used mechanism. I can't check for every obscure log function that people create.

Please, only one library/technology per answer, so they can get vote-ranked. Also, using alert() is a good short-term solution but breaks down if you want robust debug logging or if blocking the execution is a problem.

A: 

Myself, I am a firm believer in the following:

alert('Some message/variables');
Teifion
This is a good temporary solution, but fails if you are emitting info-level logging, which there's generally a lot of. The app would quickly become unusable because of all the alert()s
levik
Ahh, I assumed it was more about short term outputting of info
Teifion
Even if you were simply "outputting" info, because alert is a blocking call, it can, unfortunately, cause side effects, esp. with Ajax. I have had code behave poorly merely because of an alert placed in just the wrong place.
Jason Bunting
One of my biggest personal issue's with alert logging is that it blocks, so until the user hits okay no other script is run. That can be a detriment if you are debugging Ajax or other type code which may receive a response while you are waiting to hit okay.
Scott
+4  A: 

Firebug lite is a cross browser, lite version of Firefbug that'll at least give you console.log capabilities on most browsers.

Zach
A: 

What about Firebug Lite (for those non-Firefox browsers)? I haven't used it much except when debugging Dojo code in IE. But it tries as best it can to put a Firebug console in IE, Safari, and Opera.

Of course there is always the ever reliable 'alert (err_msg);' :D

jpbarto
A: 

There is JQuery Logging, which looks promising.

pkaeding
A: 

If you are already using jQuery, I can heartily recommend the jQuery Debug plugin (a.k.a., jquery.debug.js). See http://trainofthoughts.org/blog/2007/03/16/jquery-plugin-debug/.

This plugin allows you to switch debug logging off or on via a global switch. Logging looks like this:

$.log('My value is: ' + val);

Output is sent to console.log under Firefox and is written to a div block inserted at the bottom of the page on other browsers.

dgvid
I'm not using jQuery - as stated, I'm creating a library which MAY be loaded in a page where jQuery is present. If this happens, I'd like to use jQuery features I can rely on... But a third party plugin is a stretch...
levik
+5  A: 

I personally use Firebug/Firebug Lite and on IE let Visual Studio do the debugging. None of these do any good when a visitor is using some insane browser though. You really need to get your client side javascript to log its errors to your server. Take a look at the power point presentation I've linked to below. It has some pretty neat ideas on how to get your javascript to log stuff on your server.

Basically, you hook window.onerror and your try {} catch(){} blocks with a function that makes a request back to your server with useful debug info.

I've just implemented such a process on my own web application. I've got every catch(){} block calling a function that sends a JSON encoded message back to the server, which in turn uses my existing logging infrastructure (in my case log4perl). The presentation I'm linking to also suggests loading an image in your javascript in including the errors as part of the GET request. The only problem is if you want to include stack traces (which IE doesn't generate for you at all), the request will be too large.

Tracking ClientSide Errors, by Eric Pascarello

PS: I wanted to add that I dont think it is a good idea to use any kind of library like jQuery for "hardcore" logging because maybe the reason for the error you are logging is jQuery or Firebug Lite! Maybe the error is that the browser (cough IE6) did some crazy loading order and is throwing some kind of Null Reference error because it was too stupid to load the library correctly.

In my instance, I made sure all my javascript log code is in the <head> and not pulled in as a .js file. This way, I can be reasonably sure that no matter what kinds of curve balls the browser throws, odds are good I am able to log it.

Cory R. King
+2  A: 

MochiKit has the following functions (included here with full namespace resolution):

MochiKit.Logging.logDebug() // prefaces value with "DEBUG: "
MochiKit.Logging.log() // prefaces value with "INFO: "
MochiKit.Logging.logError() // prefaces value with "ERROR: "
MochiKit.Logging.logFatal() // prefaces value with "FATAL: "
MochiKit.Logging.logWarning() // prefaces value with "WARNING: "

There is a lot more to the MochiKit.Logging namespace than this, but these are the basics.

Jason Bunting
+3  A: 

You could try log4javascript.

Disclosure: I wrote it.

Tim Down