Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5
| From: | Justin Patrin | Date: | Sat, 28 Aug 2004 01:42:27 +0000 |
| Subject: | Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5 | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-32986@lists.php.net to get a copy of this message | ||
On Fri, 27 Aug 2004 15:44:07 -0400, Greg Beaver <cellog@php.net> wrote:
>
>
> 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.
>
Ok. It seems the overwhhelming majority likes class names if this RFC
fails. I suggest adding to the RFC that separate classes should be
used to indicate separate errors.
> 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.
>
I don't see why this has to be handled in the same RFC. Warnings are a
completely separate issue and should be handled in their own way and
in their own RFC. If we add them to this RFC, its size will double and
it will be that much harder to agree on it and get it done. Compare
this to a programming project. If you have two different tasks, you
make two different and separate functions. If you combine them, you
risk making it that much harder to make a working and maintainable
system.
> 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.
>
I'm still not clear on what this means. It's obvious that you can't
catch two exceptions at once, so do you mean how to send multiple
errors up the stack as one? Such as an aggregate exception? This was
talked about before and I can definately see it going into this RFC. I
would suggest allowing an array of exceptions to be wrapped in one
exception, similar to how the current RFC says to handle re-throwing
one exception.
> 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.
>
--
DB_DataObject_FormBuilder - The database at your fingertips
http://pear.php.net/package/DB_DataObject_FormBuilder
paperCrane --Justin Patrin--