Re: PEAR's Error Handling and PHP5

Lukas Smith wrote: > Hans Lellelid wrote: > >> Either way, though, the problem I see with proxy classes in PHP is that >> they are not very seamless: 1) you cannot use instanceof (as you note) >> or any of the class introspection functions; 2) you cannot use type >> hints; and 3) proxied classes can't make use of the SPL interfaces. I'm >> sure there are other problems too, but that already cuts out a fair >> number of the new PHP5 OO features. Since we're only talking about PHP5 > > point taken. > > so it seems to me that the following is the way to go then: > - mandate the use of PEAR_Exceptions or boolean returns Agreed. > - do not mandate that these exceptions have to be thrown, they can just > as well be returned to provide context information > => its at the developer discretion to decide if the situation is really > "exceptional" or not I disagree with the idea of returning PEAR_Exception from methods that would just as well throw them; that seems equivalent to using PEAR_Error -- and won't help the developer know how the called method will handle errors (which is what I thought this was all about). There is an exception to that, I think, though, and that is for methods like getWarnings() or getErrors() or places where you explicitly are expecting to get some Exception-looking non-exceptions (or collection of them). Of course, we probably would want a PEAR_Warning instead, but PEAR_Warning could also extend Exception so that it could be thrown under certain circumstances (or maybe PEAR_Exception would accept a PEAR_Warning as a constructor param, etc.). That seems like a different discussion (and one, I know, that has been had before), also it sounds like some of this need has been addressed by trigger_error taking objects (is that for PHP6?). > that of course means that any package that does throw exceptions becomes > fairly problematic to people who also develop in the same style as i do. > but exceptions is what the vocal masses clamor for. so if there are > unvocal masses that disagree i think they failed to make their voices > heard in time. therefore they will have to change their ways or ought to > go elsewhere for their libraries in the future - you know now that happy > rapid prototyping land we had back in the php4 days ;) We "vocal masses" are only wanting to use an OO feature that has been provided for several years now in the PHP language. It never ceases to amaze me how controversial this proposition has been in PEAR. Hans