Re: Re: [PEAR-DEV] Re: Call for Review: RFC for Error Handling in PHP5 packages

From: 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--

« previous php.pear.dev (#32499) next »