Hi, Le ven. 24 mai 2019 à 01:55, Andrea Faulds <a...@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 > >
