Re: Call for Review: RFC for Error Handling in PHP5 packages

I've already archived the thread start so sorry it's a bit off thread.. The only quick?? comment from reading the document was the naming of Exceptions in the document: In the standards section it mostly illustrates raise new MyPackage_Exception(......) which is compliant to the current standard. other parts of the document talk about | throw new ResultException( $node );| It would be good to remove those types of references, to be consistant througout, and re-inforce the standards.

     in Exception class hierarchies

It would be good to illustrate the potential error types a package may throw: PEAR_Exception <Package_Name>_Exception extends PEAR_Exception <Package_Name>_Exception_IOError extends <Package_Name>_Exception. <Package_Name>_Exception_WrongArgs extends <Package_Name>_Exception. and mention that if you only have 1 exception type, which just extends PEAR_Exception it should go in the base package filename: eg. Package/Name.php if you have mulitple exception type, or a significant addition to PEAR_Exception it should go in an Exception File: eg. Package/Name/Exception.php --------------- On Errors & Exceptions ------------ Personally I would prefer a package to either be PHP5 and throw exceptions be PHP4 and return errors I guess there is scope for using PEAR_ErrorStack in a PHP4/PHP5 type class, but I suspect it may prove a nightmare to maintain. - but I dont mind leaving that option open for anyone who wants to attempt it. Roll on the day when PHP5 is stable enough to install at my clients :) Regards Alan Davey wrote:

Hi, I'd like to invite everyone interested to review the draft coding guidelines on the usage of exceptions in PHP5 classes. After this last review phase, I'll extract the Coding Guidelines section from the document, and propose the RFC via PEPr. The page is here http://wiki.ciaweb.net/yawiki/?area=PEAR_Dev&page=RfcExceptionUse#toc30 and is world editable. Feel free to add your insights to the Coding Guidelines section. I'll take the chance to say I'm sorry for the delay in taking this text to the final stage. I've been putting out virtual fires for two weeks now -- things are calming down, though. <snip> OK, I am still of the opinion that we can differentiate between how errors are handled internally, and how the user recieves them. When I talk about a "user" I am not talking about Joe Smith who is visiting a website, I am talking about a developer using PEAR in their applications. By using PEAR_ErrorStack (with which we can use PEAR_Error, PEAR_Exception or a home brew method, giving the developer that choice) we can provide the user with a SINGLE method of retrieving errors in their code. Let me try to state why this is needed: You have a package, Foo, which is a PHP 4 package, it works fine in PHP 5 and there is not PHP 5 only port. You have a package, Bar which is a PHP 5 package. You are working with both in a single script, Foo will be using PEAR_Error whilst Bar is using PEAR_Exception, meaning we need to capture two types of errors. By using PEAR_ErrorStack, it doesn't matter that Foo is using PEAR_Error and Bar using PEAR_Exception, the user can handle BOTH in the same way. I would urge that you consider this point - we MUST unify how errors are recieved by the USER, otherwise we're going to have tangles of error handling on the users end. - Davey