Here are the first 8 paragraphs of Chapter 8 of Essential ActionScript 3.0
8. Datatypes and Type Checking
So far, we’ve developed our virtual zoo program without making a single coding error. Error-free development happens in training courses and books—and nowhere else. In real-world development, programmers make errors all the time. For example, when invoking eat() on a VirtualPet object, a programmer might make a typographical error, such as the following (notice the extra “t”):
pet.eatt(new Sushi())
Or, a programmer might make a mistaken assumption about the capabilities of an object. For example, a programmer might mistakenly attempt to invoke a method named jump() on a VirtualPet object, even though VirtualPet defines no such method:
pet.jump()
In both of the preceding cases, when the program runs in the debugger version of a Flash runtime, ActionScript will generate a reference error, indicating that the program attempted to reference a variable or method that doesn’t exist.
Errors that occur at runtime are known as "exceptions." We’ll study exceptions and the techniques for handling them in Chapter 13.
When an error occurs in a program you’re writing, you should be happy. Errors indicate the precise location and cause of something in your program that would likely cause a malfunction without your attention. For example, in response to the earlier “eatt()” typo, the debugger version of a Flash runtime would display an alert dialog containing the following message:
ReferenceError: Error #1069: Property eatt not found on
zoo.VirtualPet and there is no default value.
at VirtualZoo$iinit()[C:\data\virtualzoo\src\VirtualZoo.as:8]
The error message tells us not only the name of the file in which the error occurred, but also the specific line of code containing the error. Now that’s service. (Notice that the error message uses the term property to mean “variable or method,” as discussed in Chapter 1 under “Members and Properties.”)
As useful as runtime errors are, they have a potential drawback. They occur only when the erroneous line of code actually runs. Therefore, in a very large program, a runtime error might take a long time to surface. For example, in an adventure game that takes 10 hours to complete, an error in the final stage would take 10 hours of game-play to surface!
Luckily, rather than waiting for reference errors to occur at runtime, we can tell the compiler to report them at compile-time, before a program ever runs. To do so, we use type annotations in combination with strict mode compilation.