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

Greg Beaver wrote:

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.

But I did interpret as a personal attack. Out of all this mess, I came out with pretty large reservations on leading RFC efforts in PEAR. I spent many hours in the RFC and, in the end, negative critics outnumbered constructive critics 10 to 1. The RFC is approved, but was a harline from being plain refused. I resent the lack of early contribution. However, I acknowledge your contribution. You were one of the few who had reservations on the initial direction of the RFC and wrote them down. A lot of merit must be given to distinguish from the rest of naysayers who just woke up now. I wish we had more time to discuss the reservations you wrote on the wiki.

The fact that many people are speaking up now means that the proposal did not seem to address all of the concerns raised.

There are reservations, but in most of them I see some inexperience with exception usage, coupled with PEAR core class turf defence. Time and experience will soften these reservations, and that's why I'm so keen on the idea of alpha or beta RFCs.

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 :).

Hey, if we're measuring hours spent working on this, I'm a sure winning bet :-) In retrospective, I should have left in the wiki text all the presented downsides, relevant or no, since some of those ideas cropped up again in the mailing list discussion.

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."

Can you list the sections you feel are missing from the text? I aimed at writing a light text, and may have overcompensated. The idea of a light text is: a) Not to force PEAR developers to read huge manuals in order to comply with Coding Guidelines. Writing code is hard enough as it is, and we're not being paid here. b) Stick to pretty consentual stuff. The more restrictions are issued, the more controversy will be generated c) Impose little on the developers way. Hard, restrictive CG get ignored, or poorly followed. Its better a light CG, 100% used, than a complex CS where each dev chooses which 80% of the doc to follow. Sticking to these principles, please list the missing sections, and we can start work on that.

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

Do we have to define these? Won't we be overimposing on the developer? Remember that class naming is already covered by the current CG, so there's not much freedom left.

The question of whether to recommend using error codes vs. class names is not addressed at all.

Yes it is. Error codes are deprecated by the RFC.

It suggests raising warnings on the config example, but does not standardize this in any way. Do we expect our users to do this?

No. We expect to complement this RFC with a warning handling RFC. Warnings are more complex, and more prone to design discussions that exceptions. I postponed defining warnings, but the error handling RFC is dependant on the warning handling RFC. After all this discussion, I hope someone else other than me will lead the Warning RFC. If this one was difficult to pass, a Warning RFC is hell. I wish its author the best of luck (he'll need it).

<?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.

Yes it can be handled separately. Your example shows this perfectly. For all the mess you managed to stick in there, the example has no error handling whatsoever. Only warnings are in there. We need to define a way to handle those, naturally, but most concerns in warning handling are independent from error handling (except for upgrading/downgrading warnings/errors).

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 makes it the third time I pose you this request: Please provide a real world example where multiple errors *must* be used. The only provided example -- PEAR dependency check -- is a design skew (i.e. the original design was created around the multiple error facility, and naturally requires it). It can be done with just about the same amount of code, with equallly good design, without multiple errors. My problem with multiple errors is one of definition. In order to have a multiple error, I must, upon stumbling on the first error, continue execution on to the next one. However, if I could continue execution after the first error, then it really wasn't an error, was it? Errors are program conditions where it can't continue.

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

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