Re: [PHP-DEV] [RFC] [VOTE] PREG_THROW_ON_ERROR

Hi

On 2026-09-07 13:58, Robert Humphries wrote:
>> Arguably this specific case is a bit debatable, but as the author of 
>> the
>> throwable policy RFC, I believe that it is at least violated in 
>> spirit.
>> The goal of the throwable policy generally, and also with regard to 
>> that
>> specific paragraph is to allow reliably handling groups of errors
>> without needing to wrap every individual statement into its own
>> try-catch block.
> 
> Obviously you wrote the policy and so are best placed to interpret it
> (and I am not a core developer / person with voting rights); however I
> agree with the angle Osama is coming from here - I wouldn't say this
> is an error that is (always) part of the same group. There wasn't any
> error in the call to `preg_replace_callback` itself (or any of its
> functionality) - the error was in a way during the processing of the

Yes, I agree that this case is not entirely clear-cut - and it's good 
we're having this discussion now.

> If I have understood the other example correctly, this contradicts
> quite significantly with the CSPRNG throwing an Exception that
> `RandomException` contains - as the failure is a core issue within the
> function call itself as opposed to logic that occurs in userland.

I think there might be a misunderstanding based on how you phrased that 
paragraph. To provide a more specific example:

Consider I have a session implementation that uses Redis as its session 
storage backend. Session IDs need to be created using secure randomness, 
i.e. using the CSPRNG. Both the Redis backend and the CSPRNG can 
theoretically fail. As a user when create a new session I want to be 
able to just catch (SessionInitializedFailedException) and not care 
about whether the CSPRNG or the Redis connection failed, and I might not 
even know if it's Redis, Memcache, a File System or a MySQL database. 
Thus any underlying issues must be wrapped into a session-specific 
exception.

preg_replace_callback() is different in that I explicitly pass in a 
callback and thus I'm technically in full control over the code that is 
being executed and I can theoretically know what exceptions could 
possibly be thrown and might intentionally want to handle them 
explicitly. On the other hand, failing to execute the callback means 
that the replacing operation failed, no further callbacks will be called 
and preg_replace_callback() will not return anything - and that is a 
“running this regex failed” a.k.a. PregException situation to me.

> If anything, I would argue that under the policy this should go the
> other way and become `PregError`:
>> The Error hierarchy MUST NOT be used for errors that are expected to 
>> be thrown (and caught) during normal operation of a PHP program.
> In terms of the possible errors that could occur, I would expect at
> least `PREG_INTERNAL_ERROR`, `PREG_BAD_UTF8_ERROR` &
> `PREG_JIT_STACKLIMIT_ERROR` to be code errors that require a developer
> to need to correct their code (as my understanding of these would be
> that the pattern is invalid, or not quoted correctly, etc. Although
> `PREG_BACKTRACK_LIMIT_ERROR` & `PREG_RECURSION_LIMIT_ERROR` are more
> likely to occur based on user input, then the limit for both is
> controlled by an ini setting - so again, this likely isn't something I
> would say is expected to be thrown and caught during normal operation
> of a PHP program. The final error (`PREG_BAD_UTF8_OFFSET_ERROR`) I
> _think_ would still likely need a code change to fix it occurring -
> although I have only done a quick Google to see _when_ it may occur.

This is a good point. I agree that things like pattern compilation 
failures should be a PregError, since this is a clear programmer error 
and regular expressions are not supposed to be untrusted inputs. For the 
error error situations I would need to check as well if they are 
expected during regular operation or not. The backtrack or recursion 
limits I can see being caught intentionally to provide better error 
messages to a user (thus PregException).

Best regards
Tim Düsterhus