Re: Re: [PEAR-DEV] Re: Call for Review: RFC for Error Handling in PHP5 packages
| From: | Justin Patrin | Date: | Fri, 06 Aug 2004 18:53:07 +0000 |
| Subject: | Re: Re: [PEAR-DEV] Re: Call for Review: RFC for Error Handling in PHP5 packages | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-32499@lists.php.net to get a copy of this message | ||
On Fri, 06 Aug 2004 20:23:10 +0200, Lukas Smith <lsmith@php.net> wrote:
> Justin Patrin wrote:
>
> > On Fri, 06 Aug 2004 18:42:39 +0200, Lukas Smith <lsmith@php.net> wrote:
> >
> >>
> >>Sergio Carvalho wrote:
>
> >>Finally for PHP4/PHP5 packages we may want to ponder a solution where
> >>packages optionally return Exceptions to package users. However
> >>internally they will use PEAR_Error. I havent really pondered this
> >>through but it seems to be fairly annoying to achieve. The best idea I
> >>have come up with is that there is a stack which determines what return
> >>format to use if exceptions have been enabled. Internal calls will add
> >>to the stack telling the class to return PEAR_Errors. Once the stack of
> >>internal calls is worked off the package knows to return an Exception as
> >>the user requested. The annoying part is that either you leave creating
> >>the Exception to raiseError(), thereby screwing with the trace in the
> >>exception or you have to duplicate alot of code. Then again we are
> >>talking about a cludge here anyways.
> >>
> >
> >
> > I've written many e-mails about this very thing. Here's what I got out of it
> > 1) No one is interested
>
> probably there is simply not a nice solution around. Probably the
> solution ends up being so ugly that it doesnt make sense to bother. Just
> tkaing the chance that there might be one if we ponder a bit.
>
Actually, no one was interested. The only responses I really got back were "no".
It's probably because I was proposing changing all error handling so
that the user can choose whether an error would be a return or an
Exception.
> > 2) This would screw up the call stack (big deal)
> > 3) This would require altering current projects to add a "push error
> > handling" call to all of their methods if the actually deal with any
> > errors internally
>
> Exactly. Fairly ugly indeed.
>
> > 4) If you also allow PEAR_Exceptions to be changed back to
> > PEAR_Errors, how do you get around the normal exception bubble-up? If
> > the error mode is set to PEAR_Error, then a return will happen indtead
> > of a throw and the bubble-up doesn't happen.
>
> Uhm. I dont see why you would be changing PEAR_Exceptions back. Maybe we
> are misunderstanding eachother here. I wasnt really talking about PHP5
> packages here. I was talking about PHP4/PHP5 packages. I wasnt
> suggesting to add ugly kludges like that to PHP5 only packages.
>
Ok, we are talking about different things. However, I still doubt
anyone would go for this. For a package to be PHP5 E_STRICT compliant,
it can't work in PHP4. For a script which *works* in both, you can't
use exceptions. Sure, it might be nice to allow exceptions instead of
PEAR_Errors for forward compatibility, but this would / could screw up
internal error handling for some packages.
> regards,
> Lukas
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
DB_DataObject_FormBuilder - The database at your fingertips
http://pear.php.net/package/DB_DataObject_FormBuilder
paperCrane --Justin Patrin--