Arvids,
On Mon, Mar 12, 2012 at 4:39 AM, Arvids Godjuks
<[email protected]> 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