
A better console.log - joshuacc
http://www.devthought.com/2012/03/26/a-better-console-log/
======
snprbob86
Webkit (and Firefox?) emits _live_ objects via console.log, instead of
strings. Nothing is more frustrating than tracking down odd behavior, only to
realize way too late that you've had unreliable logs. That's why we don't use
console.log; instead we've installed a global logger object which always
prints real strings. As a bonus, it keeps a ring-buffer of log messages and on
logger.error events, it posts that buffer to the server.

EDIT: Here's a Gist: <https://gist.github.com/2210783>

------
antris
Don't we already have console.trace?

------
hcarvalhoalves
As a curiosity, the bult-in logging module from Python provides the same
features (file name, line number):
[http://docs.python.org/library/logging.html#logging.LogRecor...](http://docs.python.org/library/logging.html#logging.LogRecord)

------
sambeau
Please, people. If we mean "use" can't we just use the word "use"?

------
ajross
Sometimes I think there's a special place in hell reserved where you are
fooled into thinking you can get out if you can add just... one... more...
layer... of logging abstraction.

Or maybe this is a development phase all programmers go through where they
fixate on the mechanism for finding bugs instead of the bugs.

I mean, sure: logging files and line numbers with messages is useful
sometimes. I think we all do it when chasing bugs. But is this really
something that needs to be abstracted and pickled for posterity? Imagine
looking at dmesg or syslog output and seeing all those source files you'll
never read.

~~~
ronaldj
Webkit prints the file and line number out in console.log. I use it all the
time, but I guess that's because it also links to that point in the code.

