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

Sergio, Et al; First: sorry for the re-send, this is the complete e-mail! 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. My biggest fear is that some developers are more concerned about their own code, than about the users - we may as well just keep the code to ourselves if we make it too nasty to use. 4) It basically seems like either we implement the best kludge we can, or every single user will have to implement their own kludges to deal with all the different types of error handling. 5) This RFC is not the answer, it may seem so, but its really just the way to the evil code I posted earlier... We need to work on a different solution, even if its not the one I have proposed. 6) Your reason for not using PEAR_ErrorStack is that most people don't know it... seems to me, that same lack of knowledge also exists for exceptions. Lukas and several others professed to their lack of experience with exceptions. If they can learn exceptions, they can also learn PEAR_ErrorStack. Anyways, thats about it, it was a VERY long conversation and I think I kept poor stig up way past his bedtime - however I'm greatful for the chance to air my views to him and Alan, and to have real time feedback - as you can see, it has changed my views on the solution somewhat, but I still am vehemenantly opposed to the RFC. - Davey