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

Davey wrote:

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.

Wish I had been there. Do you have a log you can send to my personal email? (thanks in advance)

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

Unifying PEAR_ErrorStack's and Exception's approaches to error handling seems all but impossible to me, without throwing out all the advantages of exceptions (transactions, deferral of checking and correction of errors). For all the talk of unifying, to address the understandable concern of PHP4/5 coexistance, no one has shown code that can avoid going for the common denominator.

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?

This is an error, as defined in the RFC. This has to halt execution (of the method), and start recovery procedures. Recovery works as described in the wiki page (hope you all took the time to read the whole text). If backup plans are present, they will be there up the call stack, in catch handlers (not in error handling callbacks). Simple rule: You find one of these, you throw an exception. Include enough info for debugging if needed. Clear cut. The simple behaviour is a result of this fundamental difference, outlined in the wiki text: http://wiki.ciaweb.net/yawiki/?area=PEAR_Dev&page=RfcExceptionUse#toc10

    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)

You are outlining in case b) an incomplete recovery, and in case c) a complete recovery. Both are defined in the RFC: http://wiki.ciaweb.net/yawiki/?area=PEAR_Dev&page=RfcExceptionUse#toc32 Note the references to warning code in the examples. This is where Warning mechanisms plug in into error handling: Once an error has been downgraded to a warning. Error to warning downgrading should be pretty common. I imagine its possible for Warning to Error upgrade to happen, but it should be less common (e.g. The data access layer corrects a badly formed XML document, but upper layers deem XML correction unacceptable).

    Note the word "procedure" not "application" :)

Hence the following phrase in the RFC definition of error: "For the sake of definition, recovery scope is defined as the method scope. " Don't think the RFC was drawn on whim. Lots of work has been poured in there.

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.

It'd be great to have a consistent way for PHP4 and PHP5. However, (I'm repeating myself): How to do this without forfeiting the advantages of Exceptions? In PHP4 errors don't interrupt flow and don't bubble up, so they're just like warnings.

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

}

You're just reinforcing that a consistent way for PHP4 and PHP5 would be good. However, (see below)

with my solution, we'll always have: if (PEAR_ErrorStack::staticHasErrors('Whatever_Package')) { }

And I'm forced to check errors immediatly after a call, losing code transactions, I can't handle recovery at the transaction level, losing deferral of checking and I can't let the errors bubble up the call stack.

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.

Return codes and exceptions are radically diferent approaches to error handling. They're impossible to merge without losing features. (snip...)

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.

No. We're in a transitional period. Two years down the road, every package will be PHP5 compliant, and only one error checking method will exist. Your alternative will maim PHP error handling within PEAR packages indefinitely. Transitional periods suck, but that's life. Transitional hurdles will just propel people to PHP5 compliant packages. Some incentive must be there...

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.

I disagree. I feel you are very attached to return code type error handling. However, it may be that the PHP community isn't ready for exceptions -- that possibility surfaced a few times during the community process.

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.

I never said it. Had I continued to use PHP4, PEAR_ErrorStack would be the obvious choice. I think it's great. What I did say was that I abstained from commenting on migrating from PEAR_ErrorStack to PEAR_Exception, as I'm not confortable with PEAR_ErrorStack, never having used it in production and all...

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.

I'm really sorry you came so late to the discussion. I exausted my noise karma on the list calling for participation on the Wiki page, stating that it needed controversy for a balanced view. Most people ignored the call. If the RFC gets approved, you may start a new collaboration page to change it, and you'll get my participation. If the RFC gets turned down, I'll do a round of info gathering to see if minor changes may save it, otherwise I'll drop it. I won't lead an Error Handling RFC that will leave PHP5 with the same error handling PHP4 provided. Cheers, Sérgio

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc