[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pear-qa
Subject:    Re: AW: [PEAR-DEV] Re: common error handling problem - a PFC issue?
From:       "Tomas V.V.Cox" <cox () idecnet ! com>
Date:       2003-08-09 13:31:17
Message-ID: 494551484.20030809153117 () idecnet ! com
[Download RAW message or body]

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



[prev in list] [next in list] [prev in thread] [next in thread]