CodingForums.com - View Single Post - JavaScript

liorean · 03-01-2004, 07:17 PM

A: There are many approaches that you can take to debugging JavaScript. Let's discuss what you may do in the code itself first:

The most common is to insert alerts into the code, where you alert the values and types of variables, function arguments, and object properties. If you are doing code forking to support different ways of doing things, you may use confirms to force a certain path to be taken. If you want to be able to cut and paste the results, you may want to use prompts.
In an effort to get better error reporting you may use window.onerror or the try..catch statement. These may also be used to let code run without halting on errors, letting all errors be reported after the code has been executed.
Reduce hard-to-find errors that may sneak into your code by always following coding conventions such as explicitly ending statements by semicolon instead of relying on the semicolon insertion; by always using braces around the bodies of statements of the control structures (if, if..else, switch, while, do..while, for, for..in statements); by using parentheses instead of relying on operator precedence; by using consistent and verbose naming conventions; by using indentation and spacing consistently in a way that makes your source code easily readable; by avoiding automatic type casting through using explicit type casting or other methods to achieve the same effect; by using full syntaces where browsers allow shortcuts (this especially goes for ie), etc.
Run the code through js lint, which will do some work towards detecting potential coding errors.

Ok, that was what you could do in the code itself. How about the detection of errors in the code?

Use many browsers for testing your scripts while you develop them. On windows, use at least ie6w, op7 and moz. On mac, use at least saf, op7, ie5m and moz. If things doesn't work in one or more of these browsers, see if you can do them differently. If not, make a fork for the chosen browser.
In ie, be sure to turn error reporting on. If you're on windows, use the Microsoft Script Debugger. You may use the debugger keyword inside the script to turn control of the execution of the script over to the debugger, if you need to track an error down. It's recommended that you use ie primarily for testing, and use op7 or moz for debugging.
In Op7, be sure to turn on JavaScript error reporting in the JavaScript Console. The Op7 JavaScript Console is far better than the ie bug reporting, and it contains a nice tracing feature that makes it easy to see where functions are called from. It also reports correct line number, in difference to iew.
In moz there's a sea of tools. You have the Mozilla JavaScript Console which reports errors and warnings as well as allows you to do simple script evaluation. You can turn on Strict Warnings to be alerted of many more potential problematic situations. You can use the DOM Inspector to view the document tree, the stylesheets tree, the computed styles, and JavaScript objects. You can use Venkman (the Mozilla JavaScript Debugger) to get a really advanced JavaScript debugger tool. You can use Ian Hickson's JavaScript Evaluation Sidebar or one of Jesse Ruderman's JavaScript Environment, view scripts bookmarklet, JavaScript Shell or view variables bookmarklet; or my ViewScripts bookmarklet.
In konq your are pretty much on your own. Use the source code tricks.
In saf you can turn on the hidden debug menu, to display frighteningly unhelpful error messages in the system Console, as well as get access to a more useful Show DOM Tree feature, if you turn on display of the Debug menu using the following command in the terminal while Safari is not running:
Code:
```
defaults write com.apple.Safari IncludeDebugMenu 1
```

03-01-2004, 07:17 PM	PM User \| #2
liorean The thread killer Join Date: Feb 2003 Location: Umeå, Sweden Posts: 5,575 Thanks: 0 Thanked 84 Times in 75 Posts	Q: How do I debug JavaScript as used on a webpage? A: There are many approaches that you can take to debugging JavaScript. Let's discuss what you may do in the code itself first: The most common is to insert alerts into the code, where you alert the values and types of variables, function arguments, and object properties. If you are doing code forking to support different ways of doing things, you may use confirms to force a certain path to be taken. If you want to be able to cut and paste the results, you may want to use prompts. In an effort to get better error reporting you may use window.onerror or the try..catch statement. These may also be used to let code run without halting on errors, letting all errors be reported after the code has been executed. Reduce hard-to-find errors that may sneak into your code by always following coding conventions such as explicitly ending statements by semicolon instead of relying on the semicolon insertion; by always using braces around the bodies of statements of the control structures (if, if..else, switch, while, do..while, for, for..in statements); by using parentheses instead of relying on operator precedence; by using consistent and verbose naming conventions; by using indentation and spacing consistently in a way that makes your source code easily readable; by avoiding automatic type casting through using explicit type casting or other methods to achieve the same effect; by using full syntaces where browsers allow shortcuts (this especially goes for ie), etc. Run the code through js lint, which will do some work towards detecting potential coding errors. Ok, that was what you could do in the code itself. How about the detection of errors in the code? Use many browsers for testing your scripts while you develop them. On windows, use at least ie6w, op7 and moz. On mac, use at least saf, op7, ie5m and moz. If things doesn't work in one or more of these browsers, see if you can do them differently. If not, make a fork for the chosen browser. In ie, be sure to turn error reporting on. If you're on windows, use the Microsoft Script Debugger. You may use the debugger keyword inside the script to turn control of the execution of the script over to the debugger, if you need to track an error down. It's recommended that you use ie primarily for testing, and use op7 or moz for debugging. In Op7, be sure to turn on JavaScript error reporting in the JavaScript Console. The Op7 JavaScript Console is far better than the ie bug reporting, and it contains a nice tracing feature that makes it easy to see where functions are called from. It also reports correct line number, in difference to iew. In moz there's a sea of tools. You have the Mozilla JavaScript Console which reports errors and warnings as well as allows you to do simple script evaluation. You can turn on Strict Warnings to be alerted of many more potential problematic situations. You can use the DOM Inspector to view the document tree, the stylesheets tree, the computed styles, and JavaScript objects. You can use Venkman (the Mozilla JavaScript Debugger) to get a really advanced JavaScript debugger tool. You can use Ian Hickson's JavaScript Evaluation Sidebar or one of Jesse Ruderman's JavaScript Environment, view scripts bookmarklet, JavaScript Shell or view variables bookmarklet; or my ViewScripts bookmarklet. In konq your are pretty much on your own. Use the source code tricks. In saf you can turn on the hidden debug menu, to display frighteningly unhelpful error messages in the system Console, as well as get access to a more useful Show DOM Tree feature, if you turn on display of the Debug menu using the following command in the terminal while Safari is not running: Code: defaults write com.apple.Safari IncludeDebugMenu 1 Last edited by liorean; 03-26-2004 at 03:47 PM..