Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105784 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 41356 invoked from network); 24 May 2019 02:47:35 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 24 May 2019 02:47:35 -0000 To: internals@lists.php.net References: Date: Fri, 24 May 2019 01:55:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 46.195.255.12 Subject: Re: JSON_THROW_ON_ERROR implementation detail From: ajf@ajf.me (Andrea Faulds) Message-ID: Hi Dan, Please see the discussion on the original pull request: https://github.com/php/php-src/pull/2662 The existing behaviour is deliberate, was already discussed, and was part of the RFC that was accepted. So there is a high standard to meet for going back on that. The idea was to keep the two error handling approaches cleanly separated. This would mean that we could eventually change the default behaviour and deprecate the old error mechanism, if we wanted to. If you explicitly request the modern exception-based error-handling mechanism and catch the exception, which contains the error code and message, you have no good reason to then try to retrieve the same error code and message via the legacy functions. What's the advantage of mixing and matching interfaces like this? It doesn't feel like good coding practice. Sorry for the slow response. I haven't checked the internals list that frequently lately. Andrea