Re: [RFC] Errors and handling in PEAR

Hi all, Greg Beaver wrote:

Hi, I'd like to propose a new way of thinking about error-handling to amend the discussion started earlier. 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

Ok, but why not write out ERROR ? I think two letters are not much more overkill ;-) But it makes clear the constant's use! What do you exactly mean with "unique"? Unique in the package or unique in PEAR?

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. 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). 4. It is suggested to define Package_Warning and Package_Notice classes for those packages that need to pass warnings and notices to a callback function, to allow non-fatal but potential errors to be ignored, or displayed and/or logged as necessary. These should be called using PEAR::raiseError() without returning the warning/notice, to allow a callback function to catch the information for logging/display. 5. Only errors and exceptions should be returned. If an error must terminate the program execution, it is an exception. If an error must terminate the current function, but not the program execution, it is an error. If an error is a problem that need not terminate execution, or might be questionable but intended behavior, a warning should be used (for example, deprecated methods). If an error is simply a valid situation that could lead to other more serious errors, it is a notice.

I think this is a little bit complicated... Why not return Warnings and Notices? Why separate Exception and Error/Warning/Notice? I think it's important to find a solution for both: php4 and 5! Because it will last a long time til anyone of us will use php5 in all projects! (But we all want a better error handling now!) It is very important to find a way to integrate the new error handling features of php5/ZE2 into PEAR's error handling! This is the right time now to think about it... But you/we forgot the fact why I reinitiated this discussion: I want the packages to return error codes in all errors! Again: The missing error codes in many packages makes it impossible to integrate such packages into professional projects/applications! Why? In such projects/apps errors mustn't be displayed to the user like "db connection failed" or "file not found" because this has nothing to do with a well thought usability! And it is not really userfriendly when such an error leads to a hard exit/die of the script and there is only displayed a broken part of a html page... An example is Archive_Tar: I can not integrate that package into my projects because it provides no error codes only messages I do not wanna show my users! A common way to define constant names would also be great but I think the most important problem of the error handling is that error codes are not completely supported in PEAR. Ok, in the hope that some devs agree with my need of error codes I'll be back tomorrow ;-) Regards, Matthias

That's about it :) Greg