Correcting Javascript Console Alert/Errors

**Strangeplant** · 06-15-2006, 04:56 PM

Hi,

I was taking a look at the FF browser javascript console to see if there was someting happening in a particularly dense javascript page that could explain a slowness to open and found several alerts. My page is based in part on the DD script at: http://www.dynamicdrive.com/dynamici...menu/index.htm

So, figuring that these should be corrected so the parser doesn't have to attempt to correct these (and take time to do so), I went to find an online javascript validator, and found one at: http://jslint.com/ and used it with good and bad results. Sure, some of the things obviously needed to be corrected, such as using '!=' instead of the correct '!==' in a comparison, and these changes were ok, and do make things run noticeable faster. But others are not tolerated by FF, like literal notation, where 'var opt=new Array();' is acceptable but 'var opt=new Array[];' is not. And there are others too, such as '{' after an 'else' if on the same line, etc.

So, what's up and is there a reliable javascript parser, and should I even attempt to apply this to my code since it is expected to run in who-knows-what version of both javascript and JScript (IE)???

**Twey** · 06-15-2006, 05:37 PM

ECMAScript is the correct term for all the many implementations of ECMA-262, the specification of the latest version of what used to be (and usually still is) called Javascript.

'var opt=new Array();' is acceptable but 'var opt=new Array[];' is not.

That's to be expected. Array[] is not acceptable syntax, and will probably be marked as an error and stop parsing (or, worse, be error-corrected and have the parser carry on). I think what the validator would like you to do is 'var opt = [];'. This would be valid, but, insofar as I can tell, would offer no advantage over 'new Array()' other than saving some typing.

And there are others too, such as '{' after an 'else' if on the same line, etc.

Syntactically, there is no problem with this, since extraneous white-space (or lack thereof) is totally ignored except after a statement, where a linebreak can cause the insertion of a semicolon by the ECMAScript parser.

I would totally ignore the output of that verifier. It has issues with things that would cause no problems at all, such as missing out optional arguments to functions. Some of the things it says are OK, but they are all things an experienced script-writer would probably catch anyway, and it tends to attempt to force a certain style of coding on you where it has no need to be; for example, omitting braces from before single-line conditionally-executed statements. Certainly not the best tool to check your scripts with, especially if you're new and can't tell the difference between what's really a problem and what isn't.

**Strangeplant** · 06-15-2006, 05:59 PM

Well, I suspected as much from that validator. Still, I was interested in removing the java console's 'deprecated arguments usage' concerns, figuring that sooner or later I would find they were a problem. And I still don't know what the parser was looking at (no line number given).

Is there a validator that works realistically?

**Twey** · 06-15-2006, 06:04 PM

The Java console? I thought we were discussing ECMAScript?

Is there a validator that works realistically?

Not to my knowledge. Just test it in a few browsers.

'deprecated arguments usage'

Won't be a problem now, but may become one in the future. If you give an URL, I'll have a look. You must be doing something pretty unusual; I've never seen FX throw one of these.