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

Sergio Carvalho wrote:

Personally, I think this is a place where we should cut away from the ties with PHP4 error handling. PEAR_ErrorStack does a very good job

As the author of PEAR_ErrorStack, I have to say that I have no opinion yet either way on how it should be used. There is, however, a basic difference of opinion I will talk about below.

given the constraints in PHP4, but would be a drag on PHP5-only packages -- which should run in E_STRICT anyway, precluding most legacy package use anyway.

Moot point - PEAR/ErrorStack.php is php4, PEAR/ErrorStack5.php is php5 E_STRICT (class name is the same) and php5-only packages could use that. Or, users could simply delete PEAR/ErrorStack.php and rename ErrorStack5.php to ErrorStack.php, unless the PEAR installer does this automatically (which it might soon) All debating aside, the basic difference that MUST be resolved is: 1) people who clamor for E_STRICT and say BC is impossible 2) people who want BC to be possible so that migration to PHP5-only E_STRICT packages occurs. For those who are in camp (1), there is *only 1 real solution* which was proposed by Heino Gehlsen. We must have 2 separate repositories in different channels, one for PEAR php4 (and possibly php4/php5) packages, and one for PEAR php5-only packages. This will allow duplicate code that differs only in 1) error handling 2) var vs. public/protected/private as in: pear::DB would return PEAR_Error, or use PEAR_ErrorStack or whatever pear5::DB would throw exceptions and use some to-be-determined php5-only warning system for any warnings. BOTH would be "class DB" in DB.php For those who are in camp (2), there is also only 1 real solution, which is to force all packages to have a php dependency on php < 5.0 and deprecate themselves in favor of a pear5 package, or to just plain deprecate them altogether and keep legacy releases, so that it is clear that php4 is deprecated, although still fully supported. *ANY* other solution will cause endless, and much less fruitful bickering. The technical hurdles involved are tremendous - pearweb cannot be rewritten to handle channels without some serious kludging. Only a from-scratch channel server implementation will make the transition smooth. Before the PEAR project website is able and ready to support multiple channels, any solution for camp 1 is physically impossible. Those who are clamoring for E_STRICT-only php5 packages would do much more good if they were to contribute coding ideas to pearweb to implement channels rather than contribute conversation on how php4 packages aren't E_STRICT-compatible. This includes ideas on how to minimally alter the existing database, perhaps to split the database up, or other possibilities that are more practical (should they exist). Greg