Re: Re: JSON_THROW_ON_ERROR implementation detail
| From: | Nicolas Grekas | Date: | Tue, 04 Jun 2019 19:05:47 +0000 |
| Subject: | Re: Re: JSON_THROW_ON_ERROR implementation detail | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-105838@lists.php.net to get a copy of this message | ||
Hi,
Le ven. 24 mai 2019 à 01:55, Andrea Faulds <ajf@ajf.me> a écrit :
>
> 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
>
Symfony is affected too, could you please have a look at the following PR?
https://github.com/symfony/symfony/pull/31860/files
Is the added boilerplate correct? Is this behavior planned to change / be
fixed in the short term?
Global side effects are nightmare, that cannot be "by design".
Thanks for considering.
Hugs,
Nicolas
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>