Re: [RFC] [VOTE] PREG_THROW_ON_ERROR
| From: | Tim Düsterhus | Date: | Fri, 04 Sep 2026 17:51:48 +0000 |
| Subject: | Re: [RFC] [VOTE] PREG_THROW_ON_ERROR | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132428@lists.php.net to get a copy of this message | ||
Hi
On 9/4/26 19:00, Osama Aldemeery wrote:
The discussion period forI regretfully were not able to work through the list backlog after my summer vacation and thus also missed the intent to vote. I have just read through the RFC and voted against it, despite being in agreement of the general concept. Specifically: 1. I disagree with keeping the Warning on compilation errors. This feature is entirely new and opt-in, thus there are no backwards compatibility expectations or considerations. The `$e->getMessage() === preg_last_error_msg()` guarantee makes the feature much worse than it could be for compilation errors. Including all necessary information in the Exception is a must for me. 2. I disagree with the behavior of not wrapping Exceptions thrown in user callbacks: I believe the correct choice is to throw a \PregException with the Exception thrown in the callback as thePREG_THROW_ON_ERRORhas passed with no open issues, so I'm opening the vote. Recap: the RFC adds an opt-inPREG_THROW_ON_ERRORflag. Pass it to anypreg_*matching function and any PCRE error the call records is additionally thrown as a\PregException, so you can catch it instead of checking the return value. The exception's code and message matchpreg_last_error()andpreg_last_error_msg()exactly, and a call without the flag behaves exactly as it does today. RFC: https://wiki.php.net/rfc/preg_throw_on_error PR: https://github.com/php/php-src/pull/22797 Voting is open now and closes on 2026-09-18 17:00:00 UTC.
->previous exception. Not wrapping the user callback exception means that one needs a catch(Exception) with a try just around the preg_ call to reliably handle all errors during regular expression execution, which nullifies much of the benefit of having a dedicated exception class in the first place.
It also violates the exception policy in https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#throwables, which states:
If an extension uses external functionality that may throw an exception it MUST wrap any exception thrown by that functionality into an appropriate exception of its own. It MUST set the $previous property to the original exception when doing so.Best regards Tim Düsterhus