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

I'd love to see a "Returning errors" chapter in the PEAR manual. 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 -- Tomas V.V.Cox mailto:cox@idecnet.com