Arvids, On Mon, Mar 12, 2012 at 4:39 AM, Arvids Godjuks <arvids.godj...@gmail.com> wrote: > I should point out that returning false on param parsing failure on the > language level is one thing (not to mention it's not ok to do that in the > first place by my taste), but forcing that behavior on the user-land level > is kind'a too much.
To be clear, that's not what I had meant at all. I was talking about ZPP returning false internally, not what the internal functions themselves do (it's up to them to ignore the error, to go on, or raise a different error). > Consider how the code will become much more complicated - now you have to > not only to check what you pass to the functions, but you have to check what > it returns every single time (do I have to mention that false can be never > returned by the function at all except when the param parsing fails?). I agree 100%. There's also a semantic difference between an error state from the function and an error state from parameter parsing. Which is why an E_RECOVERABLE_ERROR is my preferred state, since it communicates the information properly... > What is consistent and exists on the internal language layer > not necessarily good for the user-land. I'm kind'a surprised no one thought > of that. > As I said I can live with the throwing notices and warnings (and not > E_RECOVERABLE_ERROR as I personally wanted), but returning false even not > trying to run the function is just a bad idea all over the place. I'm confused. Do you not want E_RECOVERABLE_ERROR for parameter failures? Or do you, but could live with lesser as well? I didn't quite get that part... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
