To err is human. You should be ready for error messages to pop up unexpectedly from time to time. Unfortunately, this is nearly inevitable. In the beginning, error messages will crop up rather often. At first, the main reason for it will most probably be unbalanced brackets (remember-we mentioned text editors, which support auto brace matching) or mistyping Parsers constructions.
If an error occurs, page processing will stop, all currently active SQL connections will be rolled back, and method unhandled_exception, will be called. This method will receive information on the error as well as the stack of calls that caused it. The method's work will result in a custom message to be output to a visitor. The result of the page's code with error will not be output at all. The error will also be recorded in web-server's error log.
Still, it is often desirable to intercept an error and do something useful with it. Let's assume you want to check if XML code from an untrustworthy source is correct. In this case, you do not want processing to stop, quite the contrary, you do expect an error of a certain type and want to handle it. Parser is glad to meet your wishes and gives you a powerful tool: operator try.
During a complex data processing, an error may appear in a method which is called from another one, which is, in its turn, is called from a third, and so on… How can we simply report and handle the error in this case? Use operator throw, to report the error-and handle the error on the top level. In this case you will not have to check it on all nesting levels of the method calls.
It is also very often that Parser itself or its system classes report errors. See "System errors".