Pear provides a powerful error-handling mechanism. This article shows you how to benefit from this system.
Many programs already use the Pear package. Many PHP programmers are more or less familiar with the error handling in pear. But this mechanism is not limited to pear packages--Everyone can use these methods in their classes and programs.
This article is divided into two sections: first we'll look at the functions used in the class for error handling, and then we'll look at how to handle errors based on the pear error handling mechanism.
Our example class is called CVS2DB, which inserts data from a CSV file into a table in the database. Since the data may be handwritten, their data should be validated before inserting--implement postcode. The function Import () completes the work of reading, checking, and inserting; it returns the number of corrupted records. If the value returned is greater than 0, an error recordset can be written to the new CSV file using Exportunvalid (). The typical usage is this:
Import ("./dat.csv", $DSN, ' address ') {$CD->exportunvalid ("./dat2.csv");}? >
Possible errors include the following:
The CSV file to import does not exist,
Connection to database failed,
Recordset corruption, and the CSV export file could not be created.
In the classic solution that provides the error message, you might write code like this:
Import ("./dat.csv", $DSN, ' address ') switch ($result) {case File_not_opened:...break;case database_error:...break; Default:if (0 < $result) {$CD->exportunvalid ("./dat2.csv");} else {echo ' Every Thing ok! '}}? >
This is an acceptable and common approach for short scripts-but not for large programs where error handling is often a concern. The traditional possibility of forcing the author of the class to make the final decision! In most cases, this decision is based on the idea of a call to the class at that time rather than on long-term use and reusable code. A flexible error-handling mechanism is an important part of reusable code, and the PEAR error API is one such well-tested mechanism.
class in the eyes of the user
In addition to those two functions, the class provides a set of error-handling functions and one of its own error objects called Db2cvs_error, which has a special localized error message for the feature feature.
Now I'll show you how to control the behavior of a class when an error occurs.
local and global error handling
You use Seterrorhandling () to manage error handling; This function requires two parameters: the first is the error mode, and the second (optional) parameter is the error mode specific option. For example seterrorhandling (Pear_error_print, ' This ERROR occurred%s ') and seterrorhandling (Pear_error_trigger, e_user_warning )。
The way this function is called is the most important of the general behavior: Static or entity. In class cvs2db, we can use both to set error handling, all of which have the same structure-set the error pattern for the class:
Per INSTANCE$CD = new csv2db (); $cd->seterrorhandling (Pear_error_die)://Staticcvs2db::seterrorhandling (PEAR_ Error_die); Pear::seterrorhandling (Pear_error_die);
If the two give the same result, where is the difference? Entity invocation is only for that class setting and static invocation works for all classes that use Pear_error or derive from that class. This also applies to the first static command Cvs2db::seterrorhandling (Pear_error_die)-although it appears to affect only the Cvs2db class.
Summary:Using a command as an entity function means that the error mode is set only for the entity (local), and the invocation as a static function is to set the error mode (global) for the entire script.
seterrorhandling () and RaiseError ()
All two functions can be called statically and function as entities. It's important to remember how a combination makes them interact with each other.
is basically:static invocation of seterrorhandling () only affects the static invocation of RaiseError ()--seterrorhandling () as an entity function that only affects raiseerror () as a static function call. In class csv2db, it is not feasible to use csv2db::seterrorhandling () to set the error mode because we use the $this->raiseerror (...). There's a little trick to solving this xuwu-rewriting raiseerror ():
Function RaiseError (..., $mode =null, $options =null,...) {if ($mode ==null && $this->_default_error_mode!=null) {$mode = $this->_default_error_mode; $options = $ This->_default_error_options;} Return Pear::raiseerror (..., $mode, $options,...);}
In this way, we map the entity calls to static, and if you call RaiseError () in error mode, then this pattern overrides these settings--this is the global setting.
You should be careful about how errors are thrown by the class, and if you are not careful, this can lead to undesirable side effects.
