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

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. regards, Lukas