Forum Moderators: open
I am trying to rid my page of the yellow warning triangle, it states
Line: 240
Char: 2
When I open it it dreamweaver the only thing on line number 240 is a }
Which line does the warning actually mean, I have counted down the code lines also and can't find anything that looks wrong, how else do I debug the script?
Also, make sure the {s and }s match in quantity and placement.
Without more detail it's hard to say anything further.
[edited by: WesleyC at 7:22 pm (utc) on May 22, 2008]
The line number in the error message corresponds to the line in memory at which the error occurs, after the page has been rendered with \n and \r intact (that's my theory). that means it's offset by any injected external scripts.
Thus it's possible to have an error on line 300 of a file that only has 100 lines.
Thus it's possible to have an error on line 300 of a file that only has 100 lines
That's great so there's no way of pointing to it.
My issue is on a gmap page that works out distance between two points, as it calculates it updates a text field, when adding the start point there's no problem as soon as the next point is added the yellow triangle appears, any ideas?
Have you tried the error control panel in FireFox? If it's an error that comes up only in IE, this won't be very helpful, but if it's a genuine error, FF will show the code snippet that's causing it.
as soon as the next point is added the yellow triangle appears, any ideas?
Likely to show in FF. You could paste that chunk in here, someone will spot it.
cheers
The line number in the error message corresponds to the line in memory at which the error occurs, after the page has been rendered with \n and \r intact (that's my theory). that means it's offset by any injected external scripts.Thus it's possible to have an error on line 300 of a file that only has 100 lines.
Hhhmmm, I'm not convinced...
Some argue it's completely accurate. It's always drove me nuts. :-)
Nutty, certainly! However, I too have found it to be reasonably accurate - once you figure out what file it is referring to. And that's the problem, it doesn't tell you what file the error is referring to! It could be any external or inline script. Most of the time you're just looking in the wrong file! (Well, that's my theory ;)
Here's a test:
I created four files. 1 HTML file, and 3 scripts. Complete source for each is below.
test.html
<html>
<head>
<script>
alert('inline');
</script>
<script src="test1.js"></script>
<script src="test2.js"></script>
<script src="test3.js"></script>
</head>
<body>
hello world
</body>
</html>
test1.js
alert('one');
test2.js
alert('two');
test3.js
// this is a test
document.write('hello world');
// this is a test
alert('three');
// this is a test
// this is a test
These execute fine, doing what you'd expect; four alerts (inline, one, two, three) and the words "hello world" appear twice on the page.
Now I'll introduce some errors to test3.js:
test3.js
// this is a test
document.wr[red]o[/red]te('hello world');
// this is a test
alert('three');
// this is a test
// this is a test
The error message says the problem is Line 3, Char 1. At this point, it's important to note that the line number is referring to a point in test3.js, not in test.html. The error message doesn't tell you this - you have to guess.
The error is actually on line 2, but maybe we can assume that we just subtract 1 from the line number. Padding the beginning of test3.js with extra comments seems to support this idea, since we can put the error on Line 6, and the message says Line 7, 7->8, 8->9, etc. Adding new lines and extra commands into any of the files doesn't change the offset; it always seems to be off by one. At least that's predictable, and predictable is good.
Let's produce a different kind of error, by omitting the end quote inside the alert:
test3.js
// this is a test
document.write('hello world');
// this is a test
[red]alert('three);[/red]
// this is a test
// this is a test
Now, the error says Line 5, Char 15. Since we can take "5" to actually mean "4", it holds that the problem is an unterminated string in the alert() on line 4. Good good.
Let's change the error again, omitting the right parenthesis of the alert:
test3.js
// this is a test
document.write('hello world');
// this is a test
[red]alert([/red]
// this is a test
// this is a test
This time, the error says Line 7 Char 1. There is no line "7", though I can take this to mean that the parser got to the end of the script (ie, the abyss after "6"), without finding the end of the alert() parameters. Fair enough.
I'll do something a little more complex now:
test1.js
alert('one');
function dosomething(){
document.wr[red]o[/red]te('hello world');
}
test3.js
document.write('hello world');
dosomething();
dosomething();
dosomething();
dosomething();
The error message says Line 4 Char 2. This refers to line 3 of test1.js.
So far it seems like this is true:
It's not too bad if you keep the number of scripts low, but the trend today is client-side applications getting larger, not smaller.
More massive debugging headaches happen when you're generating dynamic scripts with injected lines of data, employing conditional Lazy Loading or Javascript On Demand.
<html>
<head>
<script>
alert('inline');
</script>
</head>
<body onclick='olert(22)'>
hello world
</body>
</html>
Onclick the error reports as line 6 (should be 7), but the Microsoft script debugger correctly takes me to line 7 with olert(22) highlighted.
If it's an "unterminated" sort of error, you may get the EOF line number (as in the unfinished alert example).
I'm not denying what IE might return, but I was wondering... if in JS, CR/LF is an alternative statement separator to the ';' (semicolon) why doesn't IE just cut its loses and quit when it gets to the end of the line?!
I asserted that it was possible to get an error on line 300 when the file is 100 lines long... I swear I didn't imagine this
Perhaps you were dynamically loading content above your script? So, any error in your script would appear on a line number that was way beyond its actual line in the file? May be...?!
Perhaps you were dynamically loading content above your script
if in JS, CR/LF is an alternative statement separator to the ';' (semicolon) why doesn't IE just cut its loses and quit when it gets to the end of the line?!
It is not.
alert(
// this is a test
// this is a test
'Some Text'
);
is valid, non of the line breaks terminate the statement ?
"if in JS, CR/LF is an alternative statement separator to the ';' (semicolon) why doesn't IE just cut its loses and quit when it gets to the end of the line?!"It is not.
Sorry, yes you are right. The ';' is optional if each of your statements is on a separate line - not the same thing (and not recommeded). JS automatically inserts semicolons (to separate statements) where it thinks best.
If it's an "unterminated" sort of error, you may get the EOF line number (as in the unfinished alert example).
Another thought... if the 'unterminated' error is within a function, then the line number of the error should be the end of the function, not the EOF? At least this seemed to be so in the case of the unterminated alert() above - although this may vary I guess.
