A Detailed Look at PEAR

PEAR as a framework for building web applications is itself built on top
of a base of standard classes. These classes support basic error-handling routines, needed variables, and constants to the classes that inherit them. That is, most PEAR libraries and packages are themselves subclasses of the standard base PEAR classes.

The PEAR development team has gone to great effort to create a standard
error-handling class and emulation for destructors that is extremely
expandable so it can be used by all the other derived classes of the PEAR
Repository. This emulation for destructors on PEAR classes is very
important to programmers, as PHP itself still does not support destructors on classes.

What this means is that you need a homegrown workaround
to emulate destructors on new PEAR classes. This is important to programmers that need to run specific functions when objects are to be destroyed, or when they are not needed anymore and can be removed from PHP's memory allocation.

The standard PEAR_Error class

PEAR classes should use the PEAR_Error class to handle error routines, as
implemented on the database abstraction package PEAR::DB. This class is
used statically using the new feature of PHP 4.0, which lets
normal PHP scripts to call methods of classes without having to instantiate
an object for that class. The example below shows this feature in action:

PEAR packages do the same thing with other important PEAR classes. They usually call raiseError() to create an error object that has several pieces of information on what went wrong at the time of the error. An example from the PEAR::DB MySQL driver is as follows:

An Introduction to PEAR -- Find yourself wishing PHP had an easy way to manage additional modules? Joao Prado Maia explains PEAR and shows how it fills this role.

The code actually checks if the connection to the MySQL database server was
successful. The line that uses ini_set() turns on the PHP feature to track errors and to save these errors in a special variable called $php_errormsg.
This variable will then be checked on the next conditional statement to
determine why the connection to MySQL was not established.

More on PEAR::DB error handling

One of the nicest things about PEAR is its error-handling routines. Because PHP is an interpreted language, errors are often only discovered when users try to load your page in ways you didn't think of before. It's quite common for a developer with too little time to test his personal site to get e-mail from users saying that the site has a bug.

In some cases, the problem might be the database server that crashed, or some other reason besides his code. One good thing about PEAR error handling is that you can catch simple errors like that and use a special function to show a "Sorry, we are experiencing technical difficulties" page.

When you combine PEAR's error handling with PHP's new output buffering
functions, you can even cache the page already created and show only the error message page, as follows:

Note: you will need the output buffering functions from PHP version 4.0 and up to make the above snippet work.

That is just an example of what can be done with PEAR and PHP's error-handling functions and routines. Considering PHP is a 5-year-old scripting language, this technique is quite powerful for logging errors.