Silly Newbie Mistake

[Gene Wirchenko]

Dear JavaScripters:

At the best of time, I have found debugging JavaScript code to be
such a bother. I have been using IE's F12, but it does not handle (or
I have not figured out how) debugging an included file (<script
src=...). (If you know how, would you please let me know?) As a
consequence, I did not get immediate feedback on my silly error and
wasted a couple of hours.

You see, I have done a lot of programming in Visual FoxPro. Its
line comment token is "&&". Somehow, I typed that, instead of "//",
and I did not see it as an error for some time.

Go ahead and laugh, but it could be you next time.

Sincerely,

Gene Wirchenko

 

[Evertjan.]

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:

At the best of time, I have found debugging JavaScript code to be
such a bother. I have been using IE's F12, but it does not handle (or
I have not figured out how) debugging an included file (<script
src=...). (If you know how, would you please let me know?)

Debugging can easily be done with setting breakpoints:

......
alert( 'line 12: ' + myValueToBeRead )
......

......
if (myValueToBeRead>12) alert( 'line 345: ' + myValueToBeRead )
......

and commenting it out when not needed:

// alert( 'line 12: ' + myValueToBeRead )

Yes, I know this is not a Remedium Totalis,
breaking up time-sensitive code for instance,
but using your brain's logical programme will get you there,
as long as you understand your code-to-be-debugged in the first place.

 

[Steve Wakeford]

If you can use Firefox there is a great add-on called FireBug http://getfirebug.com/

It has an integrated line debugger with support for breakpoints, watch expressions, visible call stack. It also can be just as simple as outputting the JavaScript error that halted script execution, usually this will be all you need. Great plugin and definitely industry standard for web development.

 

[Tim Streater]

If you can use Firefox there is a great add-on called FireBug
http://getfirebug.com/

It has an integrated line debugger with support for breakpoints, watch
expressions, visible call stack. It also can be just as simple as outputting
the JavaScript error that halted script execution, usually this will be all
you need. Great plugin and definitely industry standard for web development.

For JavaScript debugging, I've never needed much more than the use of
alert(), or more conveniently console.info(), which puts messages into
Safari's error console. Safari also allows you to inspect any element
which includes all the attributes and styles for the element and where
the computed style comes from. You can also modify an element to see the
effect of style or attribute changes.

But you also have to think what you're doing. The other day I looked at
some of my code and thought, hey, I can optimise that by using
getElementById() to look for the element by id. But it didn't work. Then
I remembered why I'd coded it to look through the rows by hand: the
tbody I was searching through was not part of the DOM, so I can't use
getElementById() for that one.

 

[Jacob Block]

Dear JavaScripters:

     At the best of time, I have found debugging JavaScript code tobe
such a bother.  I have been using IE's F12, but it does not handle (or
I have not figured out how) debugging an included file (<script
src=...).  (If you know how, would you please let me know?)  As a
consequence, I did not get immediate feedback on my silly error and
wasted a couple of hours.

     You see, I have done a lot of programming in Visual FoxPro.  Its
line comment token is "&&".  Somehow, I typed that, instead of "//",
and I did not see it as an error for some time.

     Go ahead and laugh, but it could be you next time.

Sincerely,

Gene Wirchenko

I really like using Google Chrome's web tools. Just hit ctrl+shift+I
and you can look at scripts, set breakpoints and reload and trace
through programs. It gives you great information in tool-tips on all
variables and you can do some fancier stuff too. I am new at
Javascript and was wondering if there is anything better than
developing just in Chrome too (yeah I've tried Firefox's plugins, but
they don't seem as fluid). Based on these replies it seems like there
isn't. I have experience with Eclipse and haven't really looked in to
doing web development in it. I know there are some plugins, but Chrome
just seemed easier for the small stuff I've been doing.

Jacob

 

[Jacob Block]

Dear JavaScripters:

     At the best of time, I have found debugging JavaScript code tobe
such a bother.  I have been using IE's F12, but it does not handle (or
I have not figured out how) debugging an included file (<script
src=...).  (If you know how, would you please let me know?)  As a
consequence, I did not get immediate feedback on my silly error and
wasted a couple of hours.

     You see, I have done a lot of programming in Visual FoxPro.  Its
line comment token is "&&".  Somehow, I typed that, instead of "//",
and I did not see it as an error for some time.

     Go ahead and laugh, but it could be you next time.

Sincerely,

Gene Wirchenko

I should also add that you can monitor HTML and javascript in real-
time. I was reviewing a JQuery plugin slideshow plugin and HTML tags
were popping up and disappearing as I was doing the hovering. I
thought that was really cool/helpful. Not sure if other environments
can handle that. You can also make changes in real-time like someone
above mentioned of Firefox. Definitely check it out!

Jacob

 

[Gene Wirchenko]

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:


Debugging can easily be done with setting breakpoints:

When it works. When it does not, it is a bother.

[snip]

Yes, I know this is not a Remedium Totalis,
breaking up time-sensitive code for instance,
but using your brain's logical programme will get you there,
as long as you understand your code-to-be-debugged in the first place.

Since I am following a text to learn JavaScript, that is not
necessarily the case. I have found bugs in the code examples, too. It
is rather time-consuming at times.

Sincerely,

Gene Wirchenko

 

[Richard Cornford]

Dear JavaScripters:

At the best of time, I have found debugging JavaScript code
to be such a bother.

It gets easier. There is an inevitably (because we are dealing with
machines) close relationship between the error messages generated by
javascript engines so eventually the specific message text will pretty
much tell you what you need to be looking for (and where), which makes
it fairly trivial to find and fix it.

I have been using IE's F12, but it does not handle (or
I have not figured out how) debugging an included file (<script
src=...).

Not being able to debug included resources would be so useless for a
javascript debugger that this extremely unlikely to be the case.

(If you know how, would you please let me know?) As a
consequence, I did not get immediate feedback on my silly
error and wasted a couple of hours.

But your "silly error" was (almost certainly) a syntax error, so if
set up to do so IE would have popped up its error dialog as soon as it
spotted the syntax error. Trying to develop on IE while not having pop-
up its error dialog for every error will waste a great deal of time.

You see, I have done a lot of programming in Visual FoxPro.
Its line comment token is "&&". Somehow, I typed that, instead
of "//", and I did not see it as an error for some time.

That type of mistake is pretty common. The version I have seen most
often has been people used to writing VBScript trying to use its
comment delimiter in javascript. That is always going to be a syntax
error, but even though your - && - is a javascript operator it is
still unlikely that you could both semicolon terminate the statement
being commented on and/or write a worthwhile comment without the
result being a syntax error.

Remember that a syntax error will be identified when the code is
parsed, the result will never be executable, and so a debugger, as
such, will be of no use in identifying that problem because it will
not have anything executable to work with.

Go ahead and laugh, but it could be you next time.

Mistakes are inevitable, but syntax errors are not that difficult to
find and fix.

Richard.

 

[Mel Smith]

Hi:

I too use IE (actually IE7) as my test bed because my small set of users
are older people with IE as the browser.

In any case, *my* error was using the assignment operator := instead
of =

(altho I have used FoxBase, FoxPlus, and later FoxPro, for the last ten
years I've used Harbour/xHarbour for web site development. This language
uses := as the assignment operator.)

I spent two hours wondering why nothing was happening as I modified code
in my Javascript. Even the Alert() messages were not displaying.

After *finally* locating this faulty assignment operator and correcting
it, my javascript started working again.

So, altho I have Chrome and FF on my dev machine, I do most of my
primary development using IE and Javascript.

I guess I'll have to use more Chrome or FF for development.

(but again, the biggest confusion is syntactic because my language is so
much like Javascript, but again different in many small ways -- and I
program in both languages every day -- a brain buster !)

-Mel Smith

 

[Dr J R Stockton]

In comp.lang.javascript message <nojtd7pb39ofku9j7a1bi6pog635kga2ua@4ax.

At the best of time, I have found debugging JavaScript code to be
such a bother. I have been using IE's F12, but it does not handle (or
I have not figured out how) debugging an included file (<script
src=...). (If you know how, would you please let me know?) As a
consequence, I did not get immediate feedback on my silly error and
wasted a couple of hours.

But we here are smarter, and so use other browsers.

Note that the reported market share for other browsers is now
considerably greater than that for IE.

Of course, once the author's sillies have been dealt with by using other
browsers, one should use IE and try to deal with its sillies.

For code not reliant on a GUI and I/O, it may well be worth testing in
JScript under WSH. That at least gives a clear indication, in your
choice of font size, of where it thinks the error is or becomes
detectable.

 

[Gene Wirchenko]

It gets easier. There is an inevitably (because we are dealing with
machines) close relationship between the error messages generated by
javascript engines so eventually the specific message text will pretty
much tell you what you need to be looking for (and where), which makes
it fairly trivial to find and fix it.

I am not getting error messages. I simply get no page display.
This makes tracking down errors considerably more difficult and
time-consuming.

Not being able to debug included resources would be so useless for a
javascript debugger that this extremely unlikely to be the case.

The probability is 1. Note that I stipulated "(or I have not
figured out how)". A feature that I can not figure out how to use
might as well not exist. How does it work?

But your "silly error" was (almost certainly) a syntax error, so if
set up to do so IE would have popped up its error dialog as soon as it
spotted the syntax error. Trying to develop on IE while not having pop-
up its error dialog for every error will waste a great deal of time.

Yes. I have looked. Where is that setting?

That type of mistake is pretty common. The version I have seen most
often has been people used to writing VBScript trying to use its
comment delimiter in javascript. That is always going to be a syntax
error, but even though your - && - is a javascript operator it is
still unlikely that you could both semicolon terminate the statement
being commented on and/or write a worthwhile comment without the
result being a syntax error.

Which is not reported on my system.

Remember that a syntax error will be identified when the code is
parsed, the result will never be executable, and so a debugger, as
such, will be of no use in identifying that problem because it will
not have anything executable to work with.


Mistakes are inevitable, but syntax errors are not that difficult to
find and fix.

They can be if the error is not reported.

Sincerely,

Gene Wirchenko

 

[Evertjan.]

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:

When it works. When it does not, it is a bother.

Why a bother? Debugging is just the way to unbother.

[snip]

Yes, I know this is not a Remedium Totalis,
breaking up time-sensitive code for instance,
but using your brain's logical programme will get you there,
as long as you understand your code-to-be-debugged in the first place.

Since I am following a text to learn JavaScript, that is not
necessarily the case. I have found bugs in the code examples, too. It
is rather time-consuming at times.

If you "follow a text",
is understanding the code less necessary for debugging?

 

[Tim Streater]

[snip]

I am not getting error messages. I simply get no page display.
This makes tracking down errors considerably more difficult and
time-consuming.
[snip]

They can be if the error is not reported.

No decent browser is going to detect an syntax error, and then not
report it.

I just tried a small test, adding this:

+=25

in the page load handler. In Safari's case, I see (in the Error Console)
the message:

Syntax Error: unexpected token +=25

FF gives a similar message.

If in your case the page isn't being loaded you might have no syntax
error, instead a logic error that means what you think is a pointer to
some DOM item is in fact null, and execution stops right there (I'm
assuming your JS loads the page, otherwise you'd see it - in my error
case the page load completes but because JS execution doesn't, various
buttons are not disabled as normal).

Have you looked in the FF error console? (Tools -> Web Developer -.
Error Console)

 

[Gene Wirchenko]

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
[SNIP]

Why a bother? Debugging is just the way to unbother.

I have pages crash with no error message. It is then a bother to
hunt down errors. Perhaps, you have your browser set up with all of
the nifty settings for detecting AND REPORTING errors. Despite
looking for them repeatedly, I have been unable to find them.

[snip]

If you "follow a text",
is understanding the code less necessary for debugging?

No. My point is that I do not necessarily understand the code at
the time I have the problem, especially right after I have typed it
in. Did I type it in wrong? Is there a bug?

I also tend to make changes to bring the code in line with the
way I prefer for formatting, naming conventions, robustness, etc. For
example, the code often uses hard references such as parent.frames[0].
I change these by naming the frame and using the name. Sometimes,
this causes problems though less than right after typing the code in.

Sincerely,

Gene Wirchenko

 

[Tim Streater]

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
[SNIP]

Why a bother? Debugging is just the way to unbother.

I have pages crash with no error message. It is then a bother to
hunt down errors. Perhaps, you have your browser set up with all of
the nifty settings for detecting AND REPORTING errors. Despite
looking for them repeatedly, I have been unable to find them.

The browsers will report errors by default.

Have you been looking in the error consoles as I have been suggesting?

 

[Ross McKay]

At the best of time, I have found debugging JavaScript code to be
such a bother. I have been using IE's F12, but it does not handle (or
I have not figured out how) debugging an included file (<script
src=...). (If you know how, would you please let me know?) As a
consequence, I did not get immediate feedback on my silly error and
wasted a couple of hours.

I highly recommend you learn JavaScript in either Firefox with the
Firebug extension[1] or Google Chrome. The debugging tools are much
better. I guess you can also throw in Opera, as Dragonfly is pretty good
too (but slower on starting). Just load the page once, navigate to the
included scripts in the debugger, set your breakpoints, then reload.

Keep IE's tools for debugging IE-specific problems.

Also learn how to make good use of the console logging tools.[2][3]

You see, I have done a lot of programming in Visual FoxPro. Its
line comment token is "&&". Somehow, I typed that, instead of "//",
and I did not see it as an error for some time.

You might find greater happiness (less Risk!) in returning to an edit /
"compile" / test cycle, where "compile" is actually a lint pass to check
for such basic mistakes.[4][5] You'll probably need to tinker with the
config files to suppress some screaming though, as linters can be
excessively fussy at times


[1] https://addons.mozilla.org/en-US/firefox/addon/firebug/
[2] https://developer.mozilla.org/en/Using_the_Web_Console
[3] http://getfirebug.com/wiki/index.php/Console_API
[4] http://www.jslint.com/
[5] http://www.javascriptlint.com/

 

[Evertjan.]

Gene Wirchenko wrote on 08 dec 2011 in comp.lang.javascript:

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
[SNIP]

Why a bother? Debugging is just the way to unbother.

I have pages crash with no error message. It is then a bother to
hunt down errors. Perhaps, you have your browser set up with all of
the nifty settings for detecting AND REPORTING errors. Despite
looking for them repeatedly, I have been unable to find them.

I mostly do not use [your nifty] browser debuggers.

I just told you I set the necessary alert() breakpoints.

If the code does not run for syntactical reasons,
I remark out all the lines of code that could be the culprit,
and reinsert them in groups, using

//.... or /*...*/,

or my preference when debugging clientside js on an asp-page:

<script type='text/javascript'>
<% debug = true %>
......
<% if not debug then %>
....
....
<% end if %>
....

If you "follow a text",
is understanding the code less necessary for debugging?

No. My point is that I do not necessarily understand the code at
the time I have the problem, especially right after I have typed it
in. Did I type it in wrong? Is there a bug?

I also tend to make changes to bring the code in line with the
way I prefer for formatting, naming conventions, robustness, etc. For
example, the code often uses hard references such as parent.frames[0].
I change these by naming the frame and using the name.
Right

Sometimes,
this causes problems though less than right after typing the code in.

Why would that cause problems [stipulating that you understand the code?

 

[Gene Wirchenko]

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
[SNIP]

Why a bother? Debugging is just the way to unbother.

I have pages crash with no error message. It is then a bother to
hunt down errors. Perhaps, you have your browser set up with all of
the nifty settings for detecting AND REPORTING errors. Despite
looking for them repeatedly, I have been unable to find them.

The browsers will report errors by default.

If that were true, I would not be having the trouble that I am
having.

Have you been looking in the error consoles as I have been suggesting?

I can not find anything called that.

I am using IE 9.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

Gene Wirchenko wrote on 08 dec 2011 in comp.lang.javascript:

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
[SNIP]

Why a bother? Debugging is just the way to unbother.

I have pages crash with no error message. It is then a bother to
hunt down errors. Perhaps, you have your browser set up with all of
the nifty settings for detecting AND REPORTING errors. Despite
looking for them repeatedly, I have been unable to find them.

I mostly do not use [your nifty] browser debuggers.

I just told you I set the necessary alert() breakpoints.

And I have said a number of times that some errors do not get
picked up by that. The page simply does not render.

If the code does not run for syntactical reasons,
I remark out all the lines of code that could be the culprit,
and reinsert them in groups, using

//.... or /*...*/,

I have done similarly. I think that you can understand that
having to do so is much much more effort than getting a message such
as:
Syntax error in line 47 of somepage.html
and proceeding from there.

[snip]

Sometimes,
this causes problems though less than right after typing the code in.

Why would that cause problems [stipulating that you understand the code?

Oh, come on! Typos, and of course, if I am experimenting with
features, your stipulation is silly: it is not a safe bet that I
understand the code totally.

Sincerely,

Gene Wirchenko

 

[kiran]

LOL I am already there.