Related
I'm trying to troubleshoot a page with lots of JS, including ads, and something is causing window.console to be replaced which suppresses the typical console logging output that I would want to see.
Is there a way to identify which JS is overwriting window.console? Maybe trigger a breakpoint only when typeof(window.console) is modified?
Great question! And I think I can help.
Use Object.defineProperty https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty
to recreacte .log property.
Smth like this:
Object.defineProperty(console, "log", {
set: function () { throw 'Hoh!' }
});
console.log = 'abc';
I'm working on an existing project, with a lot of webpages. My task is to introduce logging og client script errors, usingsentr/raven-js.
In the docs, it says that i need to wrap the functions that I need to track in try/catch blocks - this is familiar to me, since I usually work in C#. But I don't wat to edit alle pages to wrap ALL javascript functions in try/catch. Is there a way to log ALL errors?
I tried something with window.onError = Raven.process, but I didn't get any logentries.
Can someone show me a what I'm missing? My setup is this:
var options = {
logger: 'my-test-logger',
whitelistUrls: [
/localhost/,
/localhost:2109/
]
};
Raven.config('https://<public-key-removed>#app.getsentry.com/<project-key-removed>', options).install();
window.onerror = Raven.process;
My setup was correct, except for the line:
window.onerror = Raven.process
For some reason I couldn't provoke any error to fire the logging event, but once I managed to simulate a real error, the logging worked just fine. The line:
Raven.config('https://#app.getsentry.com/', options).install();
does catch all errors.
It is important to realize that raven does not capture errors you trigger with the console. You need to put some error generating code directly in the page, or do something like this from the console:
window.setTimeout(function(){ foo() });
Also, i think that doing:
window.onerror = Raven.process
Is unnecessary, Raven already does that for you, in a much more advanced way.
Try the following code to disable logs from raven.js
Raven.config('your dsn', {
autoBreadcrumbs: {
console: false
}
});
Raven will from version 1 log all window.onerror errors by default.
See https://raven-js.readthedocs.org/en/latest/config/index.html#collectwindowerrors
Will use of the debugging feature console.log reduce JavaScript execution performance? Will it affect the speed of script execution in production environments?
Is there an approach to disable console logs in production environments from a single configuration location?
Actually, console.log is a lot slower than an empty function. Running this jsPerf test on my Chrome 38 gives stunning results:
when the browser console is closed, calling console.log is about 10 000 times slower than calling an empty function,
and when the console is open, calling it is as much as 100 000 times slower.
Not that you'll notice the performance lag if you have a reasonable number of console.… calls firing once (a hundred will take 2 ms on my install of Chrome – or 20 ms when the console is open). But if you log stuff to the console repeatedly – for instance, hooking it up through requestAnimationFrame – it can make things janky.
Update:
In this test I've also checked out the idea of a custom “hidden log” for production – having a variable which holds log messages, available on demand. It turns out to be
about 1 000 times faster than the native console.log,
and obviously 10 000 times faster if the user has his console open.
If you are going to have this on a public site or something, anyone with little knowledge on using the developer tools can read your debug messages. Depending on what you are logging, this may not be a desirable behavior.
One of the best approaches is to wrap the console.log in one of your methods, and where you can check for conditions and execute it. In a production build, you can avoid having these functions. This Stack Overflow question talks in details about how to do the same using the Closure compiler.
So, to answer your questions:
Yes, it will reduce the speed, though only negligibly.
But, don't use it as it's too easy for a person to read your logs.
The answers to this question may give you hints on how to remove them from production.
const DEBUG = true / false
DEBUG && console.log('string')
Will use of the debugging feature console.log reduce JavaScript
execution performance? Will it affect the speed of script execution in
production environments?
Of course, console.log() will reduce your program's performance since it takes computational time.
Is there an approach to disable console logs in production
environments from a single configuration location?
Put this code at the beginning of your script to override the standard console.log function to an empty function.
console.log = function () { };
If you create a shortcut to the console in a common core script, eg:
var con = console;
and then use con.log("message") or con.error("error message") throughout your code, on production you can simply rewire con in the core location to:
var con = {
log: function() {},
error: function() {},
debug: function() {}
}
Any function call will slightly reduce performance. But a few console.log's should not have any noticeable effect.
However it will throw undefined errors in older browsers that don't support console
The performance hit will be minimal, however in older browsers it will cause JavaScript errors if the users browsers console is not open log is not a function of undefined. This means all JavaScript code after the console.log call will not execute.
You can create a wrapper to check if window.console is a valid object, and then call console.log in the wrapper. Something simple like this would work:
window.log = (function(console) {
var canLog = !!console;
return function(txt) {
if(canLog) console.log('log: ' + txt);
};
})(window.console);
log('my message'); //log: my message
Here is a fiddle: http://jsfiddle.net/enDDV/
I made this jsPerf test: http://jsperf.com/console-log1337
It doesn't seem to take any longer than other function calls.
What about browsers that doesn't have a console API? If you need to use console.log for debugging, you might include a script in your production deployment to override the console API, like Paul suggests in his answer.
I do it this way to maintain original signature of console methods. In a common location, loaded before any other JS:
var DEBUG = false; // or true
Then throughout code
if (DEBUG) console.log("message", obj, "etc");
if (DEBUG) console.warn("something is not right", obj, "etc");
I prefer it doing this way:
export const println = (*args,) => {
if(process.env.NODE_ENV === "development") console.log(args)
}
and then use println everywhere in your code.
I'm building a normal webpage which requires me to load about five CSS files and ten Javascript files.
When loading them separately in the HTML page, my webpage loads fine.
Now for production, I concatenated all the Javascript into a single file, in the order needed, and all the CSS into another file. But when I try to run the web page with the concatenated files it throws an error saying:
Uncaught TypeError: undefined is not a function
On the line where jquery.min.js is being loaded in the concatenated Javascript file.
What can I do to mitigate this? I want to concatenate all files and minify them for production. Please help.
EDIT: I merged the Javascript and CSS in the order they were when they were being loaded individually and were working fine.
Assuming this problem still has not be resolved, a lot of individual files don't end their code with a semicolon. Most jQuery scripts end with (jQuery) and you need to have (jQuery);.
As separate files the script will load just fine but as one individual file you need the semicolons.
You might have to re-check the order in which you are merging the files,
it should be something like:
jquery.min.js
jquery-ui.js
any third party plugins you loading
your custom JS
This solution worked for me
;(function($){
// your code
})(jQuery);
Move your code inside the closure and use $ instead of jQuery
I found the above solution in https://magento.stackexchange.com/questions/33348/uncaught-typeerror-undefined-is-not-a-function-when-using-a-jquery-plugin-in-ma
after seraching too much
I got the same error from having two references to different versions of jQuery.
In my master page:
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
And also on the page:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"> </script>
I had this problem recently with the jQuery Validation plug-in, using Squishit, also getting the js error:
"undefined is not a function"
I fixed it by changing the reference to the unminified jquery.validate.js file, rather than jquery.validate.min.js.
#MvcHtmlString.Create(
#SquishIt.Framework.Bundle.JavaScript()
.Add("~/Scripts/Libraries/jquery-1.8.2.min.js")
.Add("~/Scripts/Libraries/jquery-ui-1.9.1.custom.min.js")
.Add("~/Scripts/Libraries/jquery.unobtrusive-ajax.min.js")
.Add("~/Scripts/Libraries/jquery.validate.js")
.Add("~/Scripts/Libraries/jquery.validate.unobtrusive.js")
... more files
I think that the minified version of certain files, when further compressed using Squishit, for example, might in some cases not deal with missing semi-colons and the like, as #Dustin suggests, so you might have to experiment with which files you can doubly compress, and which you just leave to Squishit or whatever you're bundling with.
For those out there who still couldn't fix this, I did so by changing my 'this' to '$(this)' when using jQuery.
E.G:
$('.icon').click(function() {
this.fadeOut();
});
Fixed:
$('.icon').click(function() {
$(this).fadeOut();
});
I've run into the very same issue, when mistakenly named variable with the very same name, as function.
So this:
isLive = isLive(data);
failed, generating OP's mentioned error message.
Fix to this was as simple as changing above line to:
isItALive = isLive(data);
I don't know, how much does it helps in this situation, but I decided to put this answer for others looking for a solution for similar problems.
Yes, i also I fixed it changing in the js libraries to the unminified.
For example, in the tag, change:
<script type="text/javascript" src="js/jquery.ui.core.min.js"></script>
<script type="text/javascript" src="js/jquery.ui.widget.min.js"></script>
<script type="text/javascript" src="js/jquery.ui.rcarousel.min.js"></script>
For:
<script type="text/javascript" src="js/jquery.ui.core.js"></script>
<script type="text/javascript" src="js/jquery.ui.widget.js"></script>
<script type="text/javascript" src="js/jquery.ui.rcarousel.js"></script>
Quiting the 'min' as unminified.
Thanks for the idea.
Remember: Javascript functions are CASE SENSITIVE.
I had a case where I'm pretty sure that my code would run smoothly. But still, got an error and I checked the Javascript console of Google Chrome to check what it is.
My error line is
opt.SetAttribute("value",values[a]);
And got the same error message:
Uncaught TypeError: undefined is not a function
Nothing seems wrong with the code above but it was not running. I troubleshoot for almost an hour and then compared it with my other running code. My error is that it was set to SetAttribute, which should be setAttribute.
In case there are any morons out there like me, I had this frustrating problem because I forgot a simple
new
keyword before instantiating a new object.
I just had the same message with the following code (in IcedCoffeeScript):
f = (err,cb) ->
cb null, true
await f defer err, res
console.log err if err
This seemed to me like regular ICS code. I unfolded the await-defer construct to regular CoffeeScript:
f (err,res) ->
console.log err if err
What really happend was that I tried to pass 1 callback function( with 2 parameters ) to function f expecting two parameters, effectively not setting cb inside f, which the compiler correctly reported as undefined is not a function.
The mistake happened because I blindly pasted callback-style boilerplate code. f doesn't need an err parameter passed into it, thus should simply be:
f = (cb) ->
cb null, true
f (err,res) ->
console.log err if err
In the general case, I'd recommend to double-check function signatures and invocations for matching arities. The call-stack in the error message should be able to provide helpful hints.
In your special case, I recommend looking for function definitions appearing twice in the merged file, with different signatures, or assignments to global variables holding functions.
Make sure you have commented out any commentaries. Sometimes when copying and pasting you will leave out the "/*!"
Also when you go into the console they will list your errors and you should take it one at a time. If you see "Uncaught SyntaxError: Unexpected token * " That might mean it is reading your js file and it isn't getting past the first line.
/*!
* jquery.tools 1.1.2 - The missing UI library for the Web
*
* [tools.tabs-1.0.4, tools.tooltip-1.1.2, tools.scrollable-1.1.2, tools.overlay-1.1.2, tools.expose-1.0.5]
*
* Copyright (c) 2009 Tero Piirainen
* http://flowplayer.org/tools/
* File generated: Wed Oct 07 09:40:16 GMT 2009
*/
I got this when I accidentally passed too many parameters into a jquery function that only expected one callback parameter.
For others troubleshooting: make sure you check all your jquery function calls for extra parameters.
I have a bunch of console.log() calls in my JavaScript.
Should I comment them out before I deploy to production?
I'd like to just leave them there, so I don't have to go to the trouble of re-adding the comments later on if I need to do any more debugging. Is this a bad idea?
It will cause Javascript errors, terminating the execution of the block of Javascript containing the error.
You could, however, define a dummy function that's a no-op when Firebug is not active:
if(typeof console === "undefined") {
console = { log: function() { } };
}
If you use any methods other than log, you would need to stub out those as well.
As others have already pointed it, leaving it in will cause errors in some browsers, but those errors can be worked around by putting in some stubs.
However, I would not only comment them out, but outright remove those lines. It just seems sloppy to do otherwise. Perhaps I'm being pedantic, but I don't think that "production" code should include "debug" code at all, even in commented form. If you leave comments in at all, those comments should describe what the code is doing, or the reasoning behind it--not blocks of disabled code. (Although, most comments should be removed automatically by your minification process. You are minimizing, right?)
Also, in several years of working with JavaScript, I can't recall ever coming back to a function and saying "Gee, I wish I'd left those console.logs in place here!" In general, when I am "done" with working on a function, and later have to come back to it, I'm coming back to fix some other problem. Whatever that new problem is, if the console.logs from a previous round of work could have been helpful, then I'd have spotted the problem the first time. In other words, if I come back to something, I'm not likely to need exactly the same debug information as I needed on previous occasions.
Just my two cents... Good luck!
Update after 13 years
I've changed my mind, and now agree with the comments that have accumulated on this answer over the years.
Some log messages provide long-term value to an application, even a client-side JavaScript application, and should be left in.
Other log messages are low-value noise and should be removed, or else they will drown out the high-value messages.
If you have a deployment script, you can use it to strip out the calls to console.log (and minify the file).
While you're at it, you can throw your JS through JSLint and log the violations for inspection (or prevent the deployment).
This is a great example of why you want to automate your deployment. If your process allows you to publish a js file with console.logs in it, at some point you will do it.
To my knowledge there is no shorter method of stubbing out console.log than the following 45 characters:
window.console||(console={log:function(){}});
That's the first of 3 different versions depending on which console methods you want to stub out all of them are tiny and all have been tested in IE6+ and modern browsers.
The other two versions cover varying other console methods. One covers the four basics and the other covers all known console methods for firebug and webkit. Again, in the tiniest file sizes possible.
That project is on github: https://github.com/andyet/ConsoleDummy.js
If you can think of any way to minimize the code further, contributions are welcomed.
-- EDIT -- May 16, 2012
I've since improved on this code. It's still tiny but adds the ability to turn the console output on and off: https://github.com/HenrikJoreteg/andlog
It was featured on The Changelog Show
You should at least create a dummy console.log if the object doesn't exist so your code won't throw errors on users' machines without firebug installed.
Another possibility would be to trigger logging only in 'debug mode', ie if a certain flag is set:
if(_debug) console.log('foo');
_debug && console.log('foo');
Hope it helps someone--I wrote a wrapper for it a while back, its slightly more flexible than the accepted solution.
Obviously, if you use other methods such as console.info etc, you can replicate the effect. when done with your staging environment, simply change the default C.debug to false for production and you won't have to change any other code / take lines out etc. Very easy to come back to and debug later on.
var C = {
// console wrapper
debug: true, // global debug on|off
quietDismiss: false, // may want to just drop, or alert instead
log: function() {
if (!C.debug) return false;
if (typeof console == 'object' && typeof console.log != "undefined") {
console.log.apply(this, arguments);
}
else {
if (!C.quietDismiss) {
var result = "";
for (var i = 0, l = arguments.length; i < l; i++)
result += arguments[i] + " ("+typeof arguments[i]+") ";
alert(result);
}
}
}
}; // end console wrapper.
// example data and object
var foo = "foo", bar = document.getElementById("divImage");
C.log(foo, bar);
// to surpress alerts on IE w/o a console:
C.quietDismiss = true;
C.log("this won't show if no console");
// to disable console completely everywhere:
C.debug = false;
C.log("this won't show ever");
this seems to work for me...
if (!window.console) {
window.console = {
log: function () {},
group: function () {},
error: function () {},
warn: function () {},
groupEnd: function () {}
};
}
Figured I would share a different perspective. Leaving this type of output visible to the outside world in a PCI application makes you non-compliant.
I agree that the console stub is a good approach. I've tried various console plugins, code snippets, including some fairly complex ones. They all had some problem in at least one browser, so I ended up going with something simple like below, which is an amalgamation of other snippets I've seen and some suggestions from the YUI team. It appears to function in IE8+, Firefox, Chrome and Safari (for Windows).
// To disable logging when posting a production release, just change this to false.
var debugMode = false;
// Support logging to console in all browsers even if the console is disabled.
var log = function (msg) {
debugMode && window.console && console.log ? console.log(msg) : null;
};
Note: It supports disabling logging to the console via a flag. Perhaps you could automate this via build scripts too. Alternatively, you could expose UI or some other mechanism to flip this flag at run time. You can get much more sophisticated of course, with logging levels, ajax submission of logs based on log threshold (e.g. all Error level statements are transmitted to the server for storage there etc.).
Many of these threads/questions around logging seem to think of log statements as debug code and not code instrumentation. Hence the desire to remove the log statements. Instrumentation is extremely useful when an application is in the wild and it's no longer as easy to attach a debugger or information is fed to you from a user or via support. You should never log anything sensitive, regardless of where it's been logged to so privacy/security should not be compromised. Once you think of the logging as instrumentation it now becomes production code and should be written to the same standard.
With applications using ever more complex javascript I think instrumentation is critical.
As other have mentions it will thrown an error in most browsers. In Firefox 4 it won't throw an error, the message is logged in the web developer console (new in Firefox 4).
One workaround to such mistakes that I really liked was de&&bug:
var de = true;
var bug = function() { console.log.apply(this, arguments); }
// within code
de&&bug(someObject);
A nice one-liner:
(!console) ? console.log=function(){} : console.log('Logging is supported.');
Yes, it's bad idea to let them running always in production.
What you can do is you can use console.debug which will console ONLY when the debugger is opened.
https://developer.mozilla.org/en-US/docs/Web/API/console/debug