Java Reference
In-Depth Information
var myOtherString = "World";
myString = myName + " said " + myString + " " myOtherString;
alert(myString);
There should be a + operator between " " and myOtherString in the final line of code.
Although easy to spot in just a few lines, this kind of mistake can be more difficult 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 you'll be told Error : Expected ';' by IE, Missing ; before statement by Firefox,
and SyntaxError: Unexpected identifier in Chrome. It's surprising how often this error crops up.
These most common mistakes are errors caused by the programmer. Other types of errors, called
runtime errors , occur when your code executes in the browser, and they aren't necessarily caused by
a typo or a missing curly brace or parenthesis. Runtime errors can still be planned for, as you see in
the next section.
error handling
When writing your programs, you want to be informed of every error. However, the last things
you want the user to see are error messages when you finally 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:
Conditions beyond your control can lead to errors. A good example of this is when you are relying
on Ajax to talk to the web server, and something happens to the user's network connection.
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 first place. That seems like
stating the obvious, but you should do a number of things 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.
Validate your data. If users can enter dud data that will cause your program to fail, then they
will. Make sure that a text box has data entered into it if your code fails when the text box is
empty. If you need a whole number, make sure that 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 confirms 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 something that can still go wrong.
 
Search WWH ::




Custom Search