Re: RFC::Error Handling Guidelines for PHP5 packages

Davey wrote:

OK... let me try this one more time, if it fails I will blatantly disregard the RFC and only contribute PHP 4 packages in the future - if any, sorry. I'm going to bunch errors and warnings together, because quite frankly the user will be looking out for both of them.

Uh? You should bunch errors and warnings together if they pose similar requirements from a software design perspective, not because they fall into the same class of output. They aren't similar. Errors *can* be seen as extreme severity warnings, but this perspective is a skew that breaks when using exceptions. Using exceptions, errors break program flow, while warnings don't, making them very different. Notification callbacks, for example, make no sense for exceptions, since the language already notifies the exception throw to everyone interested. Error levels make no sense either, since errors become just fatal or non-fatal, and their fatality is a result of handling, not property setting. This simplification introduced by exceptions is what I'm trying to maximize by separating exceptions and warnings. Even in output similarity, errors and warnings are different. A top level error (a top level exception bubble-up) will be presented in the page, while a warning is a recovered error, and will be logged.

I have no problems with using Exceptions, they're good, they should be used. I also see that a lot of people will be mixing PHP4 and PHP5 PEAR classes or using PHP4 classes in PHP5. Why not have it so that whether you use PHP4 or PHP5 we can access the errors in the same way?

Because, of all the people who proposed this, no one has shown me code for a way that won't forfeit deferral of error checking and recovery: http://wiki.ciaweb.net/yawiki/?area=PEAR_Dev&page=RfcExceptionUse#toc15

When we seperate the warnings from the errors, in how they're reported to the user, we're going to create some UBER messy code. Imagine if you will: 1) PHP 4 package - uses PEAR_Error for errors and warning 2) PHP 4 package - uses PEAR_Error for errors and PEAR_ErrorStack for warnings 3) PHP 4 package - uses PEAR_ErrorStack for errors AND warnings 4) PHP 5 package - uses PEAR_Exception for errors and PEAR_ErrorStack for warnings (this is the only configuration allowed by your RFC) Now imagine you want to combine them all... we're going to have to include 3 different error systems in our code... UGLY.

I find it uglier to introduce warning feature creep into exceptions so they can masquerade in two different façades, just for the sake of reducing API count.

Now, imagine this: 1) PHP 4 package - uses PEAR_Error *internally* for errors and warnings, this means all PEAR_Errors are used for is for handling error conditions within the class. 2) PHP 4 package uses PEAR_Error and PEAR_ErrorStack *internally* for errors and warnings respectively (i.e. private stack) 3) PHP 4 package uses PEAR_ErrorStack for errors and warnings *internally* (again private stack) 4) PHP 5 package uses PEAR_Exception and PEAR_ErrorStack for errors and warnings (private stack) respectively *internally* (i.e. all exceptions are caught inside the class, and none will ever reach the user) 5) PHP 5 package uses PEAR_ErrorStack for errors and warnings (private stack) *internally* - a configuration not allowed by your RFC 6) Custom error handling - these ways are not the only ways and I'm sure some packages may require a custom solution. Now, all of these packages put these errors and warnings that can't be handled internally on a global error stack - this is the ONLY way the user will recieve errors - wow, how clean.

You see, the concept of an error stack accumulating errors is not error treatment, but warning treatment. An error, by definition, prohibits further processing. If I'm trying to get a db connection and it fails, I obviously can't continue and fetch data from it. However, if I try to get a DB connection, it fails but I recover, I should issue a warning. If the incomplete recovery produces more warnings or even an error further down, these may be presented associated, and here a WarningStack is an excellent idea. For Warnings, not Errors.

This gives the package developer the free reign to do whatever they want for errors/warnings that are dealt with internally and will deliver the errors to the user via PEAR_ErrorStack The package user will then only have to deal with ONE way of catching and dealing with errors, warnings, notices, whatever. All packages can use this simple code: if (version_compare(PHP_VERSION, '5.0.0', '>=') === 1) {

    /* We're using PHP 5.0.0+ so lets use the E_STRICT compatible PEAR_ErrorStack */
    require_once 'PEAR/ErrorStack5.php';

} else {

    /* We're not using > PHP 5.0.0 so lets use the PHP 4 E_ALL compatible PEAR_ErrorStack */
    require_once 'PEAR/ErrorStack.php';

} This solution gives our developers the most freedom whilst delivering a unified (even when using PHP 4 and PHP 5 packages together) error reporting mechanism to our userbase.

Canning deferral of error checking and recovery, as well as correspondence to transactions.

As I said, this is my final attempt to inject sanity into this... although I may contact the PEAR Group on this matter, only they can really interject now that the voting process has started. - Davey

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