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

On Fri, Sep 4, 2026, at 19:51, Tim Düsterhus wrote:
> 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.

I've read this last week and this interpretation of the exception policy has taunted me since then. Tim, I think you are mistaken in your point of view on this. I'm not aware of any point where exceptions thrown in user callback methods are wrapped, but at least autoloading, a very prominent one, does not. https://3v4l.org/vYmts Changing this (in general for all user callbacks)  would be a very inconvenient BC break for many projects.

I think this policy should be read differently. I think as a language user you should not have to be aware of the implementation of a functions internals. if some function is using something that could throw an exception this implementation detail should be hidden from the user. Also because if the function is re-implemented another way this exception could change. From the perspective of the language user, a callable provided to a function is not part of the functions internals.

Specifically for this case, wrapping the users' exceptions in this RFC to me is very contra-intuïtive because it is inconsistent with other callbacks. Do you have an example where this wrapping currently takes place?

Greetings, Casper