I'd be fine with throwing exceptions in PHP 7.4, but maybe a warning
in PHP 7.4 and an exception in 8.0 then?

Things like that can be a pretty stupid error that doesn't get
noticed, and there are probably not many use cases checking the return
to be false and then not throwing an exception.

Regards, Niklas
Am Sa., 11. Aug. 2018 um 14:30 Uhr schrieb Christoph M. Becker
<cmbecke...@gmx.de>:
>
> On 10.08.2018 at 22:15, Jesse G. Donat wrote:
>
> > I'm measuring reaction for an RFC
> >
> > Essentially right now preg regex's fail silently - and you have to
> > actually check them manually with preg_last_error - something I've
> > never actually seen done in code.
> >
> > see:
> >
> > https://github.com/php/php-src/pull/2910
> > https://bugs.php.net/bug.php?id=70110
> > https://bugs.exim.org/show_bug.cgi?id=1663
> >
> > I'd like to propose that, in line with the recent JSON changes, the
> > preg methods be made to throw exceptions (or at the very least -
> > warnings) rather than fail silently as I believe this is a bad
> > behaviour.
> >
> > I personally do not have the low level coding knowledge needed to do
> > this, nor do I personally know anyone who does, so I would be
> > submitting this as a "concept"
> >
> >
> > Thank you ahead of time!
> >
> > This will be my first RFC submission, so I hope I'm doing this right.
>
> Thanks for bringing this up.  In principle, I'd like better feedback for
> failing PCRE functions, but I'm rather concerned regarding the BC break.
>  For json_(en|de)code() it was simple to just add another option flag,
> but some of the PCRE functions (e.g. preg_replace()) do not have an
> $options/$flags parameter yet, but already too many (optional)
> parameters.  Perhaps it would be best to postpone this to PHP 8, where
> additional warnings, and maybe even exceptions, would be acceptable.
>
> Anyhow, the implementation might be as simple as
> <https://gist.github.com/cmb69/a9c65af3a1462ed21b12beace502de0d>.
>
> --
> Christoph M. Becker
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to