Re: PEAR's Error Handling and PHP5

Hans L wrote:

If PEAR is a framework, then it needs to make a decision about error handling -- whether that decision be PEAR_Error or PEAR_Exception.

Actually I agree here. While I think that Exceptions lend themselves to very specific cases (exceptional states), I do think that it would be highly annoying to have to check for PEAR_Errors and PEAR_Exceptions, probably to the point where I would say its not worth it to make this distinction. IMHO I would therefore say: leave it to developer to throw Exceptions. If he wants to in a PEAR_Error callback based on the type of PEAR_Error (as in if I see an MDB2 connection error turn it into Exception). So in effect I am saying: leave it to the user of the library to decide what is an Exception and what isn't and mandate the use of PEAR_Error (or a PEAR_Error like solution - as a quick aside .. I do like what PEAR_Errorstack is trying to do, but somehow its has not won me over all the way just yet .. eventhough LiveUser is probably one of the more prolific users of PEAR_Errorstack). However in order to do this we must be more consistent with our use of PEAR_Error. Right now a lot of packages do not use error codes, let alone give a generic callback a chance at determining which package threw the PEAR_Error. Maybe the thing needs a clean up and redesign (I know that the static and non static calling has always been confusing people). Which also brings us to the E_STRICT question. On the note of E_STRICT. The fact of the matter is that forcing E_STRICT compliance will likely spell the end of cross PHP version packages. So when we talk about E_STRICT we should think about how to plan to handle the next PHP major version transition (as in PHP5 to PHP6). There are different ways to handle this. We could just say we allow no E_STRICT that are older than the required PHP version of the package. Or we say that all code needs to be E_STRICT compliant which specifies more or less that every major PHP version needs a new version of that package. If I understood the E_STRICT plans (which are still fuzzy to make matters worse) then all E_STRICT errors will be turned into fatal errors in the next major version, which also implies that it will be often not possible to write a package that will work across 3 major PHP versions. regards, Lukas