The thread killer
Join Date: Feb 2003
Location: UmeŚ, Sweden
Thanked 84 Times in 75 Posts
- 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 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:
defaults write com.apple.Safari IncludeDebugMenu 1
Last edited by liorean; 03-26-2004 at 03:47 PM..