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

Davey wrote:

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

Yes, but as Sergio mentions, you lose key features of Exceptions by adopting this solution. Sure it is *a* solution, but so is trigger_error(). Throwing & stacking are simply very different; I think that Sergio & others have illustrated that exception don't belong in stacks, because by definition they mean that program execution should not continue. What you are proposing is fundamentally very different from exceptions, and far less powerful. I see this as (and not disrespect indended here): "Instead of using cars, I have a better idea: bicycles. Bicycles also let you go places and they will make pedestrians feel safer on the road." Point being that exceptions do much, much more than the solution you are proposing.

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?

Yes, these are exceptions.

    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)

I don't see this as a separate category, more of an artificially created grey area. The question is more whether an error is unexpected & therefore warrants an exception, or whether it is an expected result and warrants just a return FALSE. E.g. Justin mentioned the authenticate() example, which IMO is a better example of grey area. Should authenticate() return FALSE if user cannot be authenticated or throw an exception? I think it should return false, but others would argue that you are asking authenticate() to do something & it is failing, so FALSE is not appropriate for the failure. This isn't really a problem, though, just a decisions that a package designer makes & then documents.

    c) procedure notice - Something the user should be aware of that             whilst it won't affect the procedure (i.e. a string is empty)

Yes, this is a WARNING. Different from exception, not addressed by the RFC. IMO warnings should be stacked & retrieved on demand. The PEAR_Error approach to forcing warnings down the throat of calling code is bad.

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

Exception operate at the level of procedures. If a procedure is unsure how to deal with something (or unsure of the severity) it should be an exception. Exceptions work beautifully in deep call stacks.

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')) { }

Yeah, but as mentioned your solution forgoes the benefits of exceptions. Agreed that the above code is ugly. There should be a method for PHP4 and one for PHP5. You know, it's really not that hard to port these packages to PHP5. For an internal project I've ported all of the Mail_* applications to PHP5 + Exceptions, and it took less than an afternoon. I don't know why people are so stuck on this issue of integrating PHP4 code into PHP5 applications. I use lots of PEAR packages, but just make them PHP5-only before using them. I look forward to when there will be an infrastructure to support coexisting versions in PEAR. -Hans