Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5

Sergio Carvalho wrote:

Greg Beaver wrote:

I was personally out of town the entire time that the RFC was in proposal stage, and only in town for 4 days during the wiki period. It's summer time, do we really have to blitzkrieg an important decision?

Two months from first email in the list to vote opening is hardly a blitzkrieg. There's a fine line between the correct speed and letting the process stall. If you go back and read my emails on the list, you'll find that I never moved forward a step without at least a week of comment silence. Its unfortunate that you were not around for two months, but its not the community process' fault.

Sergio, I never intended a personal attack. However, I did not feel that the RFC addressed all of the concerns I did in fact raise in the comment period you spoke about. It should be clear by now that in fact there were a few people who were absolutely gung-ho about the original proposal, and the majority have some slight to large reservations. The fact that many people are speaking up now means that the proposal did not seem to address all of the concerns raised. You said "add to the wiki" and I did. Lots of questions and concerns. Not enough of them actually made it into the RFC for my comfort with the RFC. Perhaps you thought (as you have expressed) my ideas were irrelevant to the issue at hand, but I spent a couple of hours formulating them, and do not agree :). You call the RFC "Error Handling Guidelines for PHP5" but it only covers a minute subset of what actually is error handling and raising. If you want a +1 from me, it should be named "When To Use Exceptions in PHP5." In fact, it does not even go into enough detail on how to name exceptions. With the current proposal, these are all allowed: - MyPackage_ExceptionSomeCondition - MyPackage_Exception_SomeCondition - MyPackage_Exception_Some_Condition The question of whether to recommend using error codes vs. class names is not addressed at all. It suggests raising warnings on the config example, but does not standardize this in any way. Do we expect our users to do this? <?php function catchWarning($errno, $errstr,...) {

    if ($errno == E_USER_WARNING) {
        $GLOBALS['warning'] = $errstr;
    }

} set_error_handler('catchWarning'); $e->doSomethingThatRaisesWarning(); if (isset($GLOBALS['warning'])) {

    // handle one kind of warning

} if (SomeOtherPackage::hasWarnings()) {

    // handle another package's custom warning mechanism that is used by $e

} if (PEAR_ErrorStack::staticHasErrors('yetanotherpackage', 'warning')) {

    // handle yet another package's warnings that use PEAR_ErrorStack

?> As you can see, the example is fast becoming unreadable as well as nearly undebuggable. This is not a question that can be handled separately. The question of how to handle multiple errors is equally necessary to standardize. Leaving this up to the developer will only hurt the users. All of these questions need to be a part of the error handling guideline before it makes it into the coding standard. This is a golden opportunity to fix ALL of the problems with PEAR_Error. I know it might seem like 2 months to you, but I have been grappling with how to successfully handle every one of these situations for over a year, and believe me, 2 months is a blitzkrieg. Greg