PHP Extension Add-on Repository (PEAR) Page 3

Error Handling

The correct way to handle errors is still a subject of discussion on the PHP-PEAR mailing
list. It is important however, that you never call die or
exit inside your packages. Doing so will prevent the application
using your package from handling the error in a more graceful fashion. You
should instead return an error to the caller, even if it is only a boolean
value. One error reporting method proposed by Sterling Hughes is to create a standard PEAR_ERROR
object that is created within your package and then returned to the caller.

<?php
class PEAR_ERROR {
    var $errno;
    var $errstr;
    var $calling_package;
    var $method;
}
//You can then use this code to 
//return an error from your package.
class fubar {
    function foo ($args) {
        if (count ($args) < 1) {
            $ret = new PEAR_ERROR;
            $ret->errno = WRONG_PARAM_COUNT;
            $ret->errstr = "Wrong parameter count";
            $ret->calling_package = "fubar";
            $ret->method = "foo";
            return ($ret);
        }
    }
}
?>

The recent release of PHP 4.0.1 also brought several enhancements to PHP’s
built-in error handling capabilities that might prove useful in creating an
error handling solution for PEAR packages.

Optional Feature Dependencies

In order to make sure your PEAR packages can be used by as many PHP developers
as possible, your code should not be dependent on optional features unless it
absolutely needs them.

One example is the magic_quotes_gpc configuration option. Proper PEAR
packages should work with or without this option enabled. Here’s an example
that does just that.

<?php
// If magic_quotes_gpc is enabled, remove those slashes.
if (get_cfg_var("magic_quotes_gpc")) {
    $arg = stripslashes($arg);
}
?>

Your code should always use the <?php … ?> syntax, since the
shorter forms <? … ?> and <% … %> may be
disabled.

Since the register_globals configuration may be disabled, your code
should make use of the appropriate HTTP_*_VARS global arrays.

Scope Issues

If your package is included from within a function, any variables you define
(outside your package’s classes and functions) will inherit the scope of the
calling function. For this reason it is a good practice to define these globals using
the $GLOBALS associative array.