Re: [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