Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59154 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 69160 invoked from network); 24 Mar 2012 19:29:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Mar 2012 19:29:47 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.153 smtp153.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.153] ([67.192.241.153:42942] helo=smtp153.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 69/A5-37560-8A02E6F4 for ; Sat, 24 Mar 2012 14:29:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 7F71C2D0120; Sat, 24 Mar 2012 15:29:42 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp25.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 341F52D00FC; Sat, 24 Mar 2012 15:29:42 -0400 (EDT) Message-ID: <4F6E20A6.1020209@sugarcrm.com> Date: Sat, 24 Mar 2012 12:29:42 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Nikita Popov CC: PHP internals References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] set_error_handler and set_exception_handler behavior From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > What people objected to: > * Stas: The bool(true) return value does not really make sense. > Instead the previous error/exception handler should be returned, as > always. > * Pierre: One shouldn't be able to reset the error/exception handler > like that in any case. This behavior should be removed and instead > there should be additional reset_error_handler() and > reset_exception_handler() functions (and also get_error_handler() and > get_exception_handler() if I got that right.) 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? 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? > What I would do: > Add 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227