Re: Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5 packages

Stig, Your concern over a PEAR_Exception API freeze is a valid one. Coding against a moving target is unacceptable, and Exception usage within PEAR can't be standardized without PEAR_Exception. I concede that the guidelines require a stable PEAR_Exception. However, I still maintain that the definition of PEAR_Exception API is outside the scope of the coding guidelines. The coding guidelines should be a short, stable document. Let's not forget this is mandatory reading for every PEAR developer. Having API descriptions in there defeats both purposes. It makes the document bulkier, and at the same time causes it to change more often -- requiring developers to keep up reading if they wish to keep current. Having been identified that normal PHP Exceptions don't have everything needed for our coding standards, the approach was one of defining what we do require out of PEAR_Exception. As a matter of fact, it's basically one thing: Exception nesting. As long as PEAR_Exception provides Exception nesting, it's A-OK. There are two things I deem essential before these guidelines may be made official. The first is a stable version of PEAR_Exception, and the second is a document on guidelines for Warning treatment -- as this RFC refers to downgrading/upgrading Exceptions into/from Warnings. Given this, are your reservations still strong enough to maintain a negative vote? Cheers, Sérgio Stig Bakken wrote:

(Thanks for pointing me to PEAR_Exception.) Please don't misunderstand this, your document definitely has its place and I appreciate the work you have but into it, but IMHO it would make more sense to start off by defining what exceptions mean to PEAR and _then_ have usage guidelines? Once these things have been worked out, I think these guidelines are appropriate. Until then, chances are that people need to rewrite code they wrote following the pre-standard guidelines.

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc