Java Reference
In-Depth Information
Although easy to spot in just a few lines, this kind of mistake can be harder to spot in large chunks of code.
Also, the error message this type of mistake causes can be misleading. Load this code into a browser and
you'll be told Error : Expected by IE and Missing ; before statement by Firefox. It's surprising how
often this error crops up.
These most common mistakes are errors caused by the programmer. There are other types of errors, called
run-time errors
, that occur when your code executes in the browser, and they aren't necessarily caused
by a typo, missing curly brace, parenthesis, or other pitfalls discussed. These types of errors can still be
planned for, as you'll see in the next section.
Error Handling
When writing your programs, you want to be informed of every error. However, the last thing you want
the user to see are error messages when you fi nally deploy the code to a web server for the whole world
to access. Of course, writing bug-free code would be a good start, but keep the following points in mind:
❑
Occasions arise when conditions beyond your control lead to errors. A good example of this is
when you are relying on something, such as a Java applet, that isn't on the user's computer and
that you have no way of checking for.
Murphy's Law states that anything that can go wrong will go wrong!
❑
Preventing Errors
The best way to handle errors is to stop them from occurring in the fi rst place. That seems like stating
the obvious, but there are a number of things you should do if you want error-free pages.
❑
Thoroughly check pages in as many browsers as possible. This is easier said than done on some
operating systems. The alternative is for you to decide which browsers you want to support for
your web page, and then verify that your code works in them. Use the browser checking code
found earlier in the topic to send unsupported users to a nice, safe, and probably boring web
page with reduced functionality, or maybe just supply them with a message that their browser
and/or platform is not supported.
❑
Validate your data. If users can enter dud data that will cause your program to fail, then they
will. Make sure that a textbox has data entered into it if your code fails if the text box is empty.
If you need a whole number, you must make sure the user entered one. Is the date the user just
entered valid? Is the e-mail address mind your own business the user just entered likely to be
valid? No, so you must check that it is in the format something@something.something.
Okay, so let's say you carefully checked your pages and there is not a syntax or logic error in sight. You
added data validation that confi rms that everything the user enters is in a valid format. Things can still
go wrong, and problems may arise that you can do nothing about. Here's a real-world example of some-
thing that can still go wrong.
One of your authors, Paul, created an online message board that relies on a small Java applet to enable
the transfer of data to and from the server without reloading the page. Paul checked the code and every-
thing was fi ne, and it continued to work fi ne after launching the board, except that in about fi ve percent
