Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59183
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F6E20A6.1020209@sugarcrm.com>
References: <CAF+90c_YZvtmQ=VadKuJ4XkTXZmKCKdm=+Zp8ga54AoOBPhkwQ@mail.gmail.com>
	<4F6E20A6.1020209@sugarcrm.com>
Date: Tue, 27 Mar 2012 15:44:04 +0200
Message-ID: <CAF+90c9y6G9k0VDSArnMHOq2n+K_n9QJy3oaTGhvMUoZNgzvBA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] set_error_handler and set_exception_handler behavior
From: nikita.ppv@googlemail.com (Nikita Popov)

On Sat, Mar 24, 2012 at 8:29 PM, Stas Malyshev <smalyshev@sugarcrm.com> wro=
te:
> I don't think ability to reset handlers by passing null is a big
> problem, and creating another four functions seems excessive to me.
> Also, the use case for the latter ones is not clear - why would you need
> old error handler if you are not changing it? If you are changing it,
> the case for getting the old one is clear - you may want to restore it
> later. But if you're not, why you'd need it?
Agree.

> As for returning true on null, I see no sense if this behavior. Can
> anybody explain to me what is it useful for? Why not return old handler
> just as it is done in all other cases of setting the handler?
Agree.

>> What I would do:
>> =A0Add support for set_error_handler(NULL) and change the return value
>> of set_error_handler(NULL)+set_exception_handler(NULL) to the previous
>> handler (i.e. Stas option). I implemented this option in this PR:
>> https://github.com/php/php-src/pull/20
>
> I think this makes sense (of course, since it's my proposal :). It is a
> behavior change, so it should be confined to master branch.
Not sure about that part. I think both changes should be considered as
bug fixes and as such should also be eligible for 5.3/5.4. The
set_error_handler(null) change has no impact on BC whatsoever and the
return value change only has a theoretical BC impact (why would you
check the return value if it is *always* true?)

Nikita