Re: My Experience with PHP5 Error Handling (and possible

Hi, Greg Beaver wrote:

Greg, sorry, but I understand "PEAR_ErrorStack geared towards exceptions" as "Let's make it easier to ignore errors, exceptions are bad as it's difficult to ignore them".

Put simply: your understanding is both false and annoying. I have stated repeatedly that I both use exceptions in my own php5 code, and that I agree with everything in the RFC. I have also stated that I didn't think the RFC goes far enough, and then even provided a way to ensure that the RFC doesn't lock us down into something premature through the idea of giving it a stability like packages. I have never said that I didn't want to use exceptions, only that we need more experience actually using them before we pin down how they *must* be used. I've also stated that Exceptions, although useful, do not solve absolutely every error-handling problem, and have posted these concerns in the wiki page. Somehow, none of them made it into the RFC.

Sorry, Greg, I was certainly barking at the wrong tree. If you look at Davey's response to your message, it is he who seems to propose using stack *instead* of exceptions.

1) handling multiple error conditions at once is very difficult with exceptions, and will need to be standardized 2) upgrading warnings to exceptions and downgrading exceptions to warnings is not difficult, but will be if it is not standardized.

After looking at the RFC in question, I can now see that its name is a bit misleading. It is named "Proposal for Error *Handling* Guidelines for PHP5 packages" while it does deal mostly with *signalling* the error conditions. Both of your points, however, do deal with error *handling*. I think they should be addressed, but in a short separate RFC: I still shudder remembering the "PEAR QA" RFC, which had a huge amount of not quite well thought-out stuff.

Your attack above is completely unfounded and has LITERALLY nothing to do with either what I've said or my code.

Sorry for this. I kinda was lost in the sheer amount of mail (bear in mind that English is not my native language). I promise to be more attentive in the future.

My statement "PEAR_ErrorStack geared towards exceptions" was clearly defined in a previous mail that you conveniently ignored. I have defined it again for your convenience. Please don't ignore this one. Currently, here is how PEAR_ErrorStack works: in php4, push() returns an array, and error info is stored internally as an array. in php5, push() returns an exception, and error info is stored internally as an array. The advantage of this approach over storing an object, as I saw it, was that the error info was simply data, and didn't force any particular implementation of error stuff the way PEAR_Error does. My plan (which I have already said) was to re-tool PEAR_ErrorStack to be more friendly to warnings and in particular, to store error information using Exception class names instead. This is because the class name can replace both the package and error code fields, simplifying the API substantially, and allowing easy promotion of a warning. Say you are trying to package a new PEAR package. You run "pear package" and pear passes in a package.xml file, and there are 6 parsing errors. If PEAR_PackageFile were to blindly throw an exception on the first one, the user would see (for instance): error: invalid package name and parsing would simply stop right there. You'd fix it, and try again, and have 6 annoying passes. Instead, while parsing, I would like to track ALL of the errors and warnings (like a php dep with the name php - the php name is ignored and unnecessary, but it may be an error, it may have been intended to be a pkg dep on a package named "PHP," although unlikely), and then afterwards raise an exception containing all of the error messages in one place. Although it might make sense to custom code something and use that, if I can provide a simple implementation of a stack for multiple errors, it will not only allow easy storage, it will allow other applications using PEAR_PackageFile to hook into the creation of each error and possibly modify how it is added to the stack, or how the error message is created, or other things that have not been thought of. Plus it would unify warning handling in a way that nothing else out there can. Exceptions are not powerful just because they are better, they are powerful because they are built-in and everyone can use them the same way, they unify error handling.

Thanks, Greg, that's a wonderful description. I'd like to repeat: this stuff requires a separate RFC as it really deals with intricacies of handling the existing errors. I think I'll support this hypothetical RFC. ;)