Re: Re: RFC::Error Handling Guidelines for PHP5 packages
| From: | Davey | 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.