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.
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=1663I'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
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
cmbecker69@gmx.de:
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=1663I'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