Re: My Experience with PHP5 Error Handling (and possible

Alexey Borzov 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. 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. Your attack above is completely unfounded and has LITERALLY nothing to do with either what I've said or my code.

There is no "PEAR_Error-like abomination" here aside from inflammatory rhetoric that serves no useful or even useless purpose.

There *is*: adding cruft to the 'throw' will force people wanting to use PEAR packages use their idiosyncrasies of error handling. We'll have another incarnation of monstrous PEAR.php for which PEAR was bashed for quite some time, instead of getting rid of it completely.

If you can provide a single line of php that successfully backs up this claim, I will fall over backwards in surprise. First of all, end-users would not see any difference in exception handling if the package uses PEAR_ErrorStack as well. Why? PEAR_ErrorStack Does Not Replace Exceptions, And Never Was Intended To Do So (TM). How many friggin times must I say this people? End users will ONLY see exceptions bubbled up from throw(). Any potentially ignorable conditions will be on the error stack, and users will want to deal with them, but since they are on a stack, the error handling can happen separate from the logic - just like exceptions. The only potential difference inside a package would be if a developer wishes to throw an exception and also store it on the stack. Why would a developer want to do this? The only reasoning I can think of would be to take advantage of unified logging. As I have said in the past, I think that a unification of PEAR_Exception and PEAR_ErrorStack ideas would work nicely. Why can't both share the same log? PEAR_ErrorStack::push() returns an Exception object in php5, and a developer *may* choose to throw this object. Where the hell is the cruft? PEAR_ErrorStack can be used with older php4 packages to ease the transition to replacement packages for applications. 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. Alexey, you have not provided a SINGLE line of code or even a verbal example of why the work I've just described is wrong. You continue to assume that PEAR_ErrorStack is designed to supplant exceptions or subvert the natural throw/catch paradigm of php5. Are we clear now? Greg