Re: [RFC] [VOTE] PREG_THROW_ON_ERROR

From: 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 for PREG_THROW_ON_ERROR has passed with no open issues, so I'm opening the vote. Recap: the RFC adds an opt-in PREG_THROW_ON_ERROR flag. Pass it to any preg_* 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 match preg_last_error() and preg_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.
I 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 the ->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

« previous php.internals (#132428) next »