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

HI Justin, Justin Patrin wrote:

Hmmm...there's nothing in Coding Guidelines like the following: You must use Exceptions for code errors.

Well, it does say: "Error conditions in PEAR packages written for PHP5 must be signaled using exceptions." Did you mean something different? (What are "code errors"?)

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". If I were writing it, authenticate() would return FALSE if it couldn't authenticate and the reason would be available via separate means (i.e. getReason()). Arguably an Exception would work too. Basically, there needs to be some room for interpretation, as it will be impossible to define what needs to be an exception, what can be a warning, what can simply be valid return values for a function. I think PEAR developers are sharp enough to make most of these decisions on their own, but doesn't mean the RFC shouldn't mention that. Cheers, Hans