On Tue, Jul 28, 2026 at 3:56 AM Osama Aldemeery <[email protected]> wrote:
>
> Hi all,
>
> Following the earlier pre-RFC discussion 
> (https://news-web.php.net/php.internals/131783), I've written this up as a 
> proper RFC: https://wiki.php.net/rfc/preg_throw_on_error
>
> Short version:
>
> a `PREG_THROW_ON_ERROR` flag you pass to any `preg_*()` call, so a PCRE error 
> throws a `\PregException` you can catch
> instead of a warning plus a `false` / `null` you have to notice and then 
> chase through `preg_last_error()`.
> Same thing `JSON_THROW_ON_ERROR` and `FILTER_THROW_ON_FAILURE` already do for 
> their functions.
> It's opt-in, so nothing changes without the flag.
>
> The flag only changes how an error is delivered. A call does exactly the same 
> thing with it or without it, byte for byte.
> The only difference is that at the end, any error the call would have 
> recorded is additionally thrown, carrying the same code and
> message `preg_last_error()`/`preg_last_error_msg()` would report.
>
> For array arguments that means the flag mirrors `preg_last_error()`...it 
> throws whatever error the same call leaves there,
> which for `preg_replace()` over an array is the last-processed entry, not the 
> first. (In the pre-RFC I'd floated throwing on the first failing element 
> instead).
> Whether the `preg_*()` functions should stop at the first failing entry is a 
> separate question about those functions, one that applies with or without the 
> flag, so it's out of scope here.
>
> The exception name is settled from the pre-RFC as `\PregException` (thanks 
> Tim) and the flag as `PREG_THROW_ON_ERROR`.
>
> Target is the next feature release after 8.6 since 8.6's beta1 is too close 
> for this to conclude discussion and a vote in time.
>
> I also saw Larry's note asking to hold new business that isn't targeting 8.6 
> until the freeze rush is over.
> This won't catch 8.6, so I'm not asking for any priority while the freeze is 
> on. But the pre-RFC discussion was already open before
> Larry's note, so I'd rather keep it ticking over quietly than restart it in 
> September.
> If someone prefers I park it until then, please say so and I will.
>
> Implementation and tests: https://github.com/php/php-src/pull/22797
>
> Thanks,
> Osama

Hi all,

Picking this back up...Quick recap first, since it's been quiet for a
couple of weeks.

`PREG_THROW_ON_ERROR` is an opt-in flag you pass to any `preg_*()` call.
With it, a PCRE error throws a `\PregException` you can catch, instead
of the current warning plus a `false` or `null` you have to notice and
then chase through `preg_last_error()`.
Same thing `JSON_THROW_ON_ERROR` and `FILTER_THROW_ON_FAILURE` already
do for their functions.

Where things landed:

- Nothing changes without the flag, byte for byte. All it changes is
how an error is delivered. At the end of a call, any error it would
have recorded is thrown as well, carrying the same code and message
`preg_last_error()`/`preg_last_error_msg()` would report.
- The exception is `\PregException` and the flag is
`PREG_THROW_ON_ERROR`, both settled back in the pre-RFC (thanks Tim).
- For array arguments the flag mirrors `preg_last_error()`. It throws
whatever error the call leaves there, which for `preg_replace()` over
an array is the last-processed entry, not the first. Whether the
functions should stop at the first failing entry is a separate
question about those functions, so it's out of scope here.

The two points raised during discussion, the exception hierarchy and
the warning behavior, are addressed in the RFC as it stands.

RFC: https://wiki.php.net/rfc/preg_throw_on_error
PR: https://github.com/php/php-src/pull/22797

So consider this my intent to vote...
Unless something new comes up, I'll open the vote in about two days.
If there's anything you'd want settled first, please bring it up now.

Thanks,
Osama

Reply via email to