Re: Re: RFC::Error Handling Guidelines for PHP5 packages

From: Date: Tue, 24 Aug 2004 14:50:29 +0000
Subject: Re: Re: RFC::Error Handling Guidelines for PHP5 packages
References: 1 2 3 4 5 6 7  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-32886@lists.php.net to get a copy of this message
Sergio, Et al; I had a *very* long discussion with both Stig and Alan on IRC last night, Alan has voted +1 on the RFC whilst Stig is seeming to be playing the devils advocate right now. Now, because of the conversation we had, I want to bring up some more points: 1) PEAR_ErrorStack may not be *the* solution, its *a* solution and will work to provide errors to all users in a uniform fashion 2) We need to stop thinking of errors like we're in PHP internals. Stig says that all errors in PEAR are warnings, of some sort. However, what I managed to come up with is this: We have:
    a) procedure fatal errors - errors that means that the class cannot
	do anything else (i.e. DB failed to connect) - these are the 			ones that the user will decide if the application should exit; 			on - but for all we know they may have a backup plan already in 		place, how will that work if *we* exit?
    b) procedure warning - Something will occur that is just as likely 			to be  what we want as what we don't (i.e. we can create a DB 			table called 'date' but it might not be too great to do so)
    c) procedure notice - Something the user should be aware of that 			whilst it won't affect the procedure (i.e. a string is empty)
    Note the word "procedure" not "application" :)
3) Both Stig and Alan were very agreeable to the fact that we need a consistant way to report errors, stig seems to feel that should span PHP4 and PHP5, whilst Alan is more of a one consistant way for PHP4 and one for PHP5. Currently, with just the PHP4 packages, we have two error solutions: PEAR_Error and boolean return values. This alone results in: if ((PEAR::isError($result) || ($result === false)) {
    // handle errors
} Now, if we throw in some PHP5 code that works with the PHP4 code we'll end up with: try {
    // some PHP5 code that might throw an exception here
    // the same PHP4 code as above
    if ((PEAR::isError($result) || ($result === false)) {
        // handle errors (or perhaps throw an exception of our own)
    }
} catch (Exception $e) {
    // deal with it
} with my solution, we'll always have: if (PEAR_ErrorStack::staticHasErrors('Whatever_Package')) { } I am going to get with Greg this week (though he doesn't know it yet!) to see how we can merge PEAR_Error and PEAR_ErrorStack so that the old ways still work, and the new work also... I think this will mean PEAR_Error just adding to the stack. Of course, this will make PEAR_Error move from stable to at least beta quality and should mean that the entire PEAR package should no longer be stable - however, a rigourous QA period might be the answer to this. I know that Greg has a tonne of tests for PEAR, these will help.

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