PHPBuilder - PHP Extension Add-on Repository (PEAR) Page 3



RSS Twitter
Articles Pear

PHP Extension Add-on Repository (PEAR) - Page 3

by: Sean Cazzell
|
July 30, 2000

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.

« Previous Page
1
|
2
|
3
|
4
Next Page »

Comment and Contribute

Your comment has been submitted and is pending approval.

Author:
Sean Cazzell

Comment:



Comment:

(Maximum characters: 1200). You have characters left.