Basic Concepts of Errors
There’s not really that much out there on errors in Actionscript 3.0 other then the documentation which can be found at this link: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/Error.html
So the goal here is to provide you with a better understanding of errors in general. We will touch on why, when and where we throw errors as well as what we can do to make those errors more effective. When used appropriately errors can do a lot for your code. By forcing a situation to be handled (throwing the error) you are making your system more reliable. If those errors convey the issue properly you are making your system more maintainable. It seems odd to learn to love the things you hate… but work with me here… 
I’m not going to go over the details of how you throw an error in code, check out the documentation as there is already plenty of info on that.
Errors are usually thrown from code that for some reason cannot complete execution. In most cases the situation is either the code not being used properly, or the code not being in a suitable state for execution. To illustrate this, suppose we are constructing the navigator of a website. The job of the navigator is to handle the details of moving between the pages in the website.
Our navigator’s navigateToPage( pageID ) method will throw two errors. One error will be thrown if you call navigateToPage with a pageID which does not exist, and the other error is thrown if you call navigateToPage while the navigator is already in the process of navigating to a page. The first error is an example of the code not being used properly, the second error is an example of the code not being in a suitable state for execution.
Errors themselves have two purposes. They notify the system that something has gone wrong, and provide the person maintaining the code in that system with information which helps them resolve that error. We can illustrate this by again taking a look at our navigator example from earlier.
Any time an error is thrown using throw the system is automatically notified. That means it’s really just about providing the right kind of information.
Remember that our navigateToPage method throws two errors. We could simply just provide a message for both errors that says “Navigator could not navigate to the page.”, or we could provide a little bit of information that helps narrow down the error. For instance, if an invalid page id is specified we could provide a message that says “Invalid page id specified”, and if the navigator is already navigating to a page we could say “Navigator is already navigating to a page”. Nothing new or complicated with any of this. It’s mostly just important that the issue that caused the error is immediately identifiable.
There is my view on errors. Here is a section on some basic things to think about regarding errors…
- Do NOT ignore errors by having an empty catch block. Respect the error for what it is, and resolve it.
- Remember that when you throw an error from a method of an object that the object and application can continue running. Always leave the object in a desirable state even if the desired state is some pre-defined undesirable state.
- If an error is not caught it will throw a dialogue which lists the error’s name, the message and then the stack trace of where the error occured. This means that when throwing an error there is no need to specify where the error was thrown from.