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