In function code, when I do this:
eval( 'var default = 100;' );
alert( default );
the browser's JS engines* will throw a Syntax Error on the second statement, as if the first statement executed successfully.
See here: http://jsfiddle.net/4FMdy/ (open the browser's console to view the error log)
However, when I remove the second statement from the code, so that I only have this:
eval( 'var default = 100;' );
the browser's JS engines will throw a Syntax Error on that statement.
See here: http://jsfiddle.net/4FMdy/1/
I don't understand this. If the first statement throws a syntax error (as it should), why does only the second statement throw such an error in my first example above. From what I understand, if a statement throws an error, that necessarily means that all previous statements (of the same call) executed successfully.
Btw, the syntax error is thrown because default is a reserved word in JavaScript, so it cannot be used as a variable name.
Also, no "eval is evil" comments please. I'm just trying to understand the behavior of the browser's JS engines.
* I tested in Firefox, and Chrome
Just an assumption:
The script-block first will be parsed, but not executed(the eval)
The browser detects only the syntax-error in line#2 and didn't execute complete script-block, so he will not determine the syntax-error in eval()
When you put the 2 lines in 2 different script-element you'll receive both errors:
http://jsfiddle.net/doktormolle/CfRmj/
Because "default" is Javascript reserved keyword :)
So alert(default) throws "syntax error" if code is checked if is correct, but then the function eval is runned, and process wount get here because of first error.
Related
I have a utility function that I use 93 times, let's call it function add(a,b){return a + b}
I am getting a TypeError: a is undefined in the console at the moment.
Usually when something similar happens, Firefox provides a trace of the line numbers of the code that calls add below the error message, allowing me to get back to the cause. However, this time there is no further information.
I've considered adding a break point in the add function, however because it gets called so much, it is impractical.
How should one trace the source of a TypeError in a heavily used javascript function?
Edit:
As pointed out by Jonas Wilms, the simplifed example will not produce a TypeError. Consider this instead:
function add(a,b){
if (typeof a != 'string'){
throw Error('my TypeError')
}
return a + b
}
Edit:
I solved this by doing ctrl-F on add( and stepping through each call until I spotted where undefined inputs were. I still have a feeling there's a better way! Or perhaps a way to arrange code so that this doesn't happen.
If I write
try { null = foobar } catch(e) { alert( e ) };
nothing is alerted, but a ReferenceError is logged in the console. However,
try { barfoo = foobar } catch(e) { alert( e ) };
shows an alert with a ReferenceError.
So the question is: what types of errors in what context get caught by try-catch statements?
So, your first line of code is invalid JavaScript syntax. That's why you're getting a:
ReferenceError: Invalid left-hand side in assignment (You can't assign vars to null)
Your second line is valid syntax, but throws a:
ReferenceError: foobar is not defined.
Now, the reason the second line does get caught, but the first one doesn't, is because the JavaScript interpreter is throwing the first error when interpreting the code, compared to when it's actually executing it, in the second example.
A more simple explanation, courtesy of #Matt:
It's simply invalid JavaScript syntax vs runtime errors. The latter get caught, the former doesn't.
You can sort of thinking it as the JavaScript interpreter looking at all the code before it executes it and thinking does that all parse correctly? If it doesn't, it throws an uncatchable Error (be it a SyntaxError or ReferenceError). Otherwise, the code beings to execute, and at one point you enter the try/catch block during execution and any runtime errors thrown whilst in there are caught.
In a recent day I faced with this kind of error message, that has no position specified. Debugging becomes much more difficult. What did I do wrong?
When I started re-define JSON.parse functions of my objects, after that appears it first time.
I replaced them to normal functions, but the error message is still strange.
Maybe because I'm writing prototype functions, and I call them before constructing a new object?
Is it because I call a function from console?
I managed to simplify the error:
var o = {g : false};
function f(){
console.log(o.g());
}
If I call it from Chrome and form console, than I will not get any line number.
I get this error and I've managed to narrow it down to:
aaa
That line of code is now the only thing in my source code and still I get the error in title. Any idea why so?
Even when surrounded with the appropriate HTML elements (html, head, body etc) I am still thrown the error. The error shows up in Chrome dev console and via alert if I include a
window.onerror
function in the head tag. It also occurs when the myFunction() method actually exists. As far as I can gather, there is absolutely nothing wrong with that above statement whatsoever.
Use
aaa
void expects a parameter.
There's an interesting discussion on using void(0) or other techniques here.
Is because void takes one argument.
You want:
aaa
void is an operator, not a function. It requires a single expression as its operand. () is not a valid expression. The correct syntax is:
aaa
You can put parentheses around 0, but they're not necessary, just as you don't need parentheses around 0 when writing 3 + 0.
I just got the following error in a piece of javascript (in Firefox 3.5, with Firebug running)
cannot access optimized closure
I know, superficially, what caused the error. I had a line
options.length()
instead of
options.length
Fixing this bug, made the message go away. But I'm curious. What does this mean? What is an optimized closure? Is optimizing an enclosure something that the javascript interpretter does automatically? What does it do?
I had this issue too when Firebug is running.
It seems to happen sometimes, when an exception is raised (for whatever reason) and when there's a recursive function call somewhere in the call stack. The exception gets re-raised as the mysterious "InternalError: cannot access optimized closure"
Changing the way I define the recursive function, seems to make this issue go away. eg changing from
function foo(bar) {... foo(recursively); ...}
to
var foo = function(bar) {... foo(recursively); ...}
Hope that helps.
It is a bug in Firefox happening with Firebug open:
https://bugzilla.mozilla.org/show_bug.cgi?id=505001
[An earlier answer mentioned this was due to this other bug, which I think is incorrect as that other problem was not related to Firebug.]
Seems like a Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=496790
A closure is a function with context. If you dynamically create a new function, then you create a closure.
function makeAdder(int num) {
return function(int num2) { return num + num2; }
}
adder = makeAdder(5);
adder(7) // returns (5+7) = 12
adder(2) // returns (5+2) = 7
Here, the closure is the inner function, as returned by makeAdder, along with the '5' that was passed.
The javascript engine might choose to optimize away the function shown above, to make things run faster, never generating or running that code, so it can't be debugged or referenced. Optimizers are supposed to be very careful to ensure there's no impact, so I'd guess this one made a mistake.
http://ludex-marketing.com/blog/2009/12/google-analytics-javascript-error-cannot-access-optimized-closure-in-ga-js/
This can also be caused by a simple race condition. I was just refactoring a 'startup' object that does a few things before the document is ready. As soon as I tried to access a second object defined immediately below the startup object I received this error.
I was under the impression that script execution waited until all of the code was compiled. Clearly that's not the case. Waiting for document ready to call methods on the second object fixed the problem. Also, using this nice 'dump()' function confirms that the second object is only partially defined when the error occurs: http://www.openjs.com/scripts/others/dump_function_php_print_r.php
I encountered the same error today. In my case this occurred because I was referencing an object's attribute or function that did not exist or was not available. I'm guessing that since the object was available via a closure that was optimized, firebug could not access metadata on that object and thus the cryptic error message.
This also happened to me today. Firebug error'd at line 2 of this function:
function IsValidDate(objName) {
re = new RegExp('^( +|today|pdate|- *\\d+ *(day(s|)|week(s|))+ *$', 'i');
if (re.test(objName.value)) return 2;
return (chkdate(objName));
}
When I added "var " before the declaration of "re" in line 1, the error went away.
There is an exception being raised somewhere else in your code within the function that has this error. It could be as simple trying to access a variable that doesn't exist.
I think we need to get a Firebug dev in here to answer why it doesn't give a more specific error as to where in the closure that raised the exception to prompt the error.
You pasted options.length(), but it is not what prompted the error. What caused the error is the fact that your bug was inside a closure.
function(){
array.length()
}
that gives the error