Re: AW: [PEAR-DEV] Re: common error handling problem - a PFC issue?

Tomas V.V.Cox wrote:

I'd love to see a "Returning errors" chapter in the PEAR manual.

You'll get it as soon as error codes are a requirement in all packages ;-) Matthias

On Monday, July 28, 2003 23:07, Greg Beaver wrote:

Here's a CS proposal:

All errors returned must be based on an error code. This error code must be referred to only as a constant name, and never directly by the number code.

Error constants shall follow the naming conventions for regular constants followed by "ERROR_". For instance, errors in the DB class must be prefaced by DB_ERROR_. All error codes must have an association with a default error message, defined in a global variable that follows the naming conventions for a regular global variable. This global variable shall be an associative array, indexing error constants to error messages. For packages that require internationalization, the array may either be replaced by error messages for another language, or itself contain arrays indexed by language code [Greg note: this should be the standard 2-letter code used by phpdoc, no? de, en, etc.].

Under no circumstances should a package ever directly access the error code by number. if define("DB_ERROR_FIRST", 1); is used, then references to DB_ERROR_FIRST must always be used, and never references to 1. This will allow future flexibility in error codes.

This, by the way, is a perfect example of why some global variables should be made semi-public. If an error message is inappropriate to a particular product, it can be modified by an end-user without tampering directly with the original source.

Greg