Re: PEAR.php to PHP5

From: Date: Sat, 19 Jun 2004 14:36:40 +0000
Subject: Re: PEAR.php to PHP5
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-30932@lists.php.net to get a copy of this message
Tomas V.V.Cox wrote:
Arnaud Limbourg wrote:
ErrorStack is forward compatible with php5. Haven't test it yet but it is designed that way (from what I've read from Greg's posts).
The point is that the adoption of ErrorStack would force loads of packages to rewrite its error handling for not saying the huge ammount of apps using the already standard PEAR::isError|raiseError().
I don't understand how this relates to error handling between the packages. For example if Log2 calls [M]DB2 to perform a query and wishes to use PEAR_ERROR_THROW with try/catch to handle the error, does log change the current PEAR error handling to do this? & when it's done is Log required to change it back? It seems to me that all PEAR classes are going to have to be rewritten to be E_STRICT compliant on PHP5. I think rewriting the error handling is pretty trivial. Currently PEAR.php does work at least with PHP5 in non-strict mode, right? I think a more progressive PHP5 solution would be to add that observer functionality into PEAR_Exception. And have the constructor signal observers. PEAR_Exception::addObserver('name', array($obj, 'methodName')); And then just throw new PEAR_Exception("Msg", ERR_CODE); Very simple, no more redundant baseclass, and seems to provide the flexibility that people are complaining is missing from Exception. Moreover, this happens to be exactly the same as the error handling practice that will be followed by non-PEAR PHP5 world. I don't think there's anything that's gonna be "forward compatible" and be E_STRICT. I can't think of a way to write anything (OO) that works in PHP4 and is E_STRICT in PHP5. That being the case, this is a great opportunity to fix error handling by taking advantage of built-in language feature designed to solve this problem. Hans

« previous php.pear.dev (#30932) next »