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

Hi Jon, Jon Wood wrote:

Also, there's no mention of the possiblity of returning status codes instead of throwing an Exception. See discussion: http://wiki.ciaweb.net/yawiki/?area=PEAR_Dev&page=RfcExceptionUse#toc27 IMHO, all failures should be required to be an exception. Return values for statuses may be used, but if functions such as checkAuthentication(), not authenticate(). If you call authenticate(), you're assuming the function *will* authenticate. If it fails, it is nto doing what the function says it will do....namely authenticate.

Yeah, this is a tricky one. I don't know if the Exception RFC really needs to describe this scenario, but perhaps a line like "other return types may be acceptible in certain situations".

Personally I think that this is self explanatory, in the way that the RFC is describing Exceptions for *error handling*, although there is a section on not using them to get out of deep recursion, which could be extended I guess.

You're probably right. The real question is probably not so much allowing for alternate ways of expressing errors (that I think would be a mistake), but rather having a flexible definition of what an error is. I think Sergio provided this definition in the RFC: "An error is defined as an unexpected, invalid program state from which it is impossible to recover." I might qualify that last part by putting it something like this: "An error is defined as an unexpected, invalid program state from which the immediate context is unable to recover." But either way, I think this provides a pretty strict definition. The authenticate() example would not fit IMO for at least a couple of those reasons. Of course, acknowledging grey areas is probably sometimes a good idea too. Don't need to give any extra ammunition to trigger-happy PEAR CS police :) Hans