Re: [RFC] Errors and handling in PEAR

Arnaud Limbourg wrote:

1. All packages that raise unique errors must define special error constants with a prefix of the package name followed by ERR_, as in PHPDOCUMENTOR_ERR_INVALID_TAG

Constants will become long, but readability can be improved with that.

2. Error constants will never be referred to by number, only by constant name. To resolve conflicts between packages, the returned error's getType() method must be used to determine which package an error came from.

Makes sense. I don't quite get the getType part. getType() is an alias to get_class($error), so you can check whether it is a 'phpdocumentor_error' or 'db_error'.

The reason for this, is this conflict: define('PHPDOCUMENTOR_ERROR_THIS', 1); ... define('DB_ERROR_THAT', 1); PHPDOCUMENTOR_ERROR_THIS == DB_ERROR_THAT, so you need to know which error class it is to resolve the error code.

3. All packages that raise unique errors must extend PEAR_Error with an error class named Package_Error, as in PhpDocumentor_Error, and must use this error class in returning all unique errors. If there is a difference between an error and exception, the Package_Exception class should be defined and used to throw a fatal exception. An example of this difference is a fatal documentation error in PhpDocumentor (error), and an invalid input to a function in PhpDocumentor (exception).

Well, some packages don't need to redefine PEAR_Error. I'll have to read the last two points more carefully. Arnaud. Without unique error classes, we need some other method of determining which application an error originates in. Sub-classing is a simple method that is supported without any changes to PEAR code. I'm open to other possibilities, but this seemed easiest.

Greg