views:

77

answers:

3

Note: Firebug being Firebug extension and/or Webkit developer tools.

With the faking of calling file I mean the link at the right side of the console output, pointing to the location where the output function (like console.log) is called.

This becomes a problem when you have unified handler for error messaging etc, thus all the console.log calls originate from the same file & linenumber.

Is there any way to fake this information? Or bake such link (pointing to line number) into the firebug console log (providing one has the stacktrace)? Just adding the filename and line number to the end of any log adds noise to the console output, making it messy.

A: 

Taking a brief trawl on the firebug forums it seems to imply that it (sometimes?) looks at the exception to determine what the line number is.

So you may well be able to fake it that way by judicious massaging.

wombleton
Hmm? How would I exactly proceed doing that? Doesn't the exception need to be thrown in the code files, or is it possible to inject filename and line number to exception somehow?
crappish
If you have unified error handling you can presumably iterate through any error it receive's properties to take a look at what Firebug might be using.
wombleton
A: 

With Firebug there is an option to show the call stack alongside errors. Click on the down arrow next to the console tab's name to see and activate it. It causes a 'plus' icon to show to the left of the message, which reveals the stack. This might get you closer the code that caused the error.

If you will also need to log errors with console.error() to make use of this. (not sure how compatible this is with chrome though)

Qazzian
The problem with this approach is that you don't still get to see the line where the log was called. Plus, Chrome doesn't have stack trace support (as far as I can see). :/
crappish
+1  A: 

Most modern browsers define a console.log function. How about instead of writing your own error handler, you go ahead and call console.log everywhere you have an error. Then, for the browsers that do not define console.log, you can define it yourself using whatever you want. For instance, if you wanted to alert the error in IE (or FF without firebug installed.. etc) you could use this code:

<html>
<head>
    <title>Test</title>
</head>
<body>
    <button onclick="throwError()">
        Throw Error</button>

    <script type="text/javascript">
        function throwError() {
            console.log("error here!");
        }

        if (!window.console) {
            window.console = {
                log: function(e) {
                    alert(e);
                }
            };
        }

        //Added in EDIT: in production add these lines below to overwrite browser's console.log function
        window.console.log = function(e) {
            alert("production alert: " + e); //or whatever custom error logging you want
        };
    </script>

</body>
</html>

You can add whatever you want to the console object. I've tested this in IE8 and Firefox, and I'm fairly confident you can make this idea work for whatever set of browsers you support.

EDIT: Looks like you can also overwrite the default console.log function in Firefox, Safari, and Chrome. Just remap the log member of the console object to a new function that does whatever you want while in production.

InvisibleBacon
The reason I have unified handler for debug messages is that as it is a simple plugin to the framework, I can simply remove it from production environment, thus not littering the user with errors. Plus, it gives me a possibility, in production environment, to push error messages from client machine to server.
crappish
That makes sense. How about you overwrite the console.log function in production? See my edits to the code and description.
InvisibleBacon
The solution seems quite interesting, as I could simple overload the console.log/error, thus catching all the debug messages. However, I still lose the actual code location the console.log was called from.
crappish
What do you mean? If you comment out the production lines above, the console.log that runs is the built in Firebug version so the code location should be reported as normal. Unless your talking about getting code location in production. You're right about that. But I'm not sure if you have any options there.
InvisibleBacon