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

Stephan Schmidt wrote:

Hi,

So i would propose to make error codes required as fast as possible.

But then we should offer some guidelines on error codes,i.e. - how to group them (use 1,2,3,4 or 10,20,30) - should constans be defined for each code - how should they be names etc. Stephan

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