In this chapter we've looked at the less exciting part of coding, namely bugs. In an ideal world we'd get things right the first time, every time, but in reality any code more than a few lines long is likely to suffer from bugs.
We then installed the script debugger, which works with Internet Explorer. Without the script debugger any errors throw up messages, but nothing else. With the script debugger we get to see exactly where the error might have been and to examine the current state of variables when the error occurred. Also, we can use the script debugger to analyze code as it's being run, enabling us to see its flow step-by-step, and check variables and conditions.
We then looked at Venkman, the script debugger for Netscape Navigator 7. We saw it has very similar functionality to the IE debugger and in some ways is superior to it. Although these debuggers have different interfaces, their principles are the same.
Some errors are not necessarily bugs in our code, but in fact exceptions to the normal circumstances that cause our code to fail, such as a Java applet failing due to a user being behind a firewall. We saw that the try...catch statements are good for dealing with this sort of error. Also when used with the throw statement, we can use the catch clause to deal with errors that are likely to happen, such as user input errors. Finally, we saw that if we want a block of code to execute regardless of any error, we can use the finally clause.
In the next chapter we'll be looking at a way of storing information on the user's computer using something called a cookie. Although they may not be powerful enough to hold a user's life history, they are certainly enough for us to keep track of a user's visits to our website and what pages they view when they visit. With that information we can provide a more customized experience for the user.