Re: [PHP-DEV][PRE-RFC] PREG_THROW_ON_ERROR flag

[email protected] (Tim Düsterhus) Thu, 09 Jul 2026 11:03:24 +0200
Newsgroups php.internals
Message-ID <[email protected]>
Hi

On 2026-07-07 03:17, Osama Aldemeery wrote:
> I'd like to propose adding a `PREG_THROW_ON_ERROR` flag to the 
> `preg_*()`
> functions, and gauge interest in that.

I personally hate this kind of flag, because of its opt-in nature. But 
given the precedent and unless and until we rebuild the regex API in a 
clean and modern way, it makes sense to me as a “stop-gap” solution that 
should allow to get rid of some custom userland code that wraps pcre 
into explicit checks.

> Passing it to any `preg_*()` call makes a PCRE error throw a
> `Pcre\PcreException` that carries the `PREG_*_ERROR` code and the
> `preg_last_error_msg()` text

Pcre\PcreException would technically be fully in line with the naming 
and Throwable policy, by including the extension name as the prefix. 
However the existing PCRE functions use `preg_` as a prefix, it will 
probably be confusing to have the two different prefixes here. Given 
that, I would suggest going with an unnamespaced \PregException for now 
and then only introduce a namespace when actually building a new API to 
not paint us into a corner already.

The naming policy specifically allows for that:

> When adding new symbols to existing extensions it is RECOMMENDED to be 
> consistent with existing symbols, rather than to follow the namespacing 
> guidelines.

and

> Newly introduced extensions MUST follow the following rules, existing 
> extensions SHOULD follow the rules for newly introduced exceptions, but 
> MAY diverge for consistency with existing symbols.

-

>    2. Whether `*_ON_ERROR` reads better than `*_ON_FAILURE` given the
>    existing `preg_last_error()`/`PREG_*_ERROR` vocabulary.

I would go with ERROR for the reasons you mentioned there.

Best regards
Tim Düsterhus