Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10122
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20040527213949.29052.qmail@pb1.pair.com>
To: internals@lists.php.net
References: <20040527155047.GA36904@gravitonic.com> <20040527184929.GB23166@csh.rit.edu> <20040527190601.45769.qmail@pb1.pair.com> <20040527200440.GA38203@gravitonic.com>
Date: Thu, 27 May 2004 14:39:48 -0700
Lines: 30
Subject: Re: [PHP-DEV] [patch] re-invoking default error handler
From: pollita@php.net ("Sara Golemon")

> 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