Re: Re: Call for Review: RFC for Error Handling in PHP5 packages

On Fri, 06 Aug 2004 18:42:39 +0200, Lukas Smith <lsmith@php.net> wrote: > > > Sergio Carvalho wrote: > > > I'd like to invite everyone interested to review the draft coding > > guidelines on the usage of exceptions in PHP5 classes. After this last > > review phase, I'll extract the Coding Guidelines section from the > > document, and propose the RFC via PEPr. The page is here > > > > http://wiki.ciaweb.net/yawiki/?area=PEAR_Dev&page=RfcExceptionUse#toc30 > > > > and is world editable. Feel free to add your insights to the Coding > > Guidelines section. > > > > I'll take the chance to say I'm sorry for the delay in taking this text > > to the final stage. I've been putting out virtual fires for two weeks > > now -- things are calming down, though. > > One thing I dont see mentioned there is the ability to expect() errors. > I dont know ErrorStack well enough yet, but IIRC it has a similar feature. > > This allows you to create a stack of errors which should not call the > default error handler. This can ease your life in certain situations > where you would have to have a try/catch block for a number of method > calls to prevent breaking the normal script execution. > > This however is only the case if you are essentially expecting any kind > of error possible because otherwise you would also have to look if the > error returned was expected or not. So I guess for most cases this is > probably another case of making it possible to not handle an error. So I > guess my point is not really novel at all :-) > > However the disadvantage "Lack of flexibility for Error Handling > Schemes" tangles itself up in a specific example. The real point there > is simply the fact that you are forced to handle every error. So maybe > it would be nice if that could be clarified, since all the comments just > delute this very important point, which will likely become the deciding > factor in all of this. > > 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 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 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. > 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--