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

Greg Beaver wrote:

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. An error code should be above '10'

(just to be prepared...)

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, ok.

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. +-0, see bottom

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.]. not ok

If you want to provide localized error messages extend PEAR_Error and override getMessage()

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. ok

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. hm, an error message should give an developer (user of an class) a hint what happends and should never lack to an application user, i doesn't understand why you want to change messages text (BTW: don't forget the

addUserInfo() method)