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