Re: [patch] re-invoking default error handler

> Of course there is a BC problem. Current error handlers do not have to > return anything. Once the patch is added, the default handler will all > of a sudden be invoked, when the developer did not really mean it. I > realize that the "convention" is to return false if you didn't process > it, but in our case we have to invert it. > We don't necessarily *have* to. Unless people are explicitly returning a false value (as opposed to simply not using return) we can make the distinction. Recall that not returning anything is passed as a return value of NULL. So we could say "If NULL, don't invoke internal handler, otherwise convert to boolean and use 'normal' logic". i.e. False we call internal handler, True we don't. This just means replacing the first line of that patch with: if (Z_TYPE_P(retval) != IS_NULL && !zend_is_true(retval)) { Here the only BC break potential is if someone out there has an error callback that does explicitly return a non-null false value. The question "why?" comes to mind, but it's not entirely out of the question. So let's tighten it down even further maybe.... if (Z_TYPE_P(retval) == IS_BOOL && Z_LVAL_P(retval) == 0) { Here, the ONLY way the internal error handler will be called is if the script explicitly returns FALSE (not 0, not blank string, not empty array, etc...). But maybe that's a bit pedantic..... -Sara