Re: [RFC] [Discussion] PREG_THROW_ON_ERROR

From: Date: Thu, 30 Jul 2026 18:56:40 +0000
Subject: Re: [RFC] [Discussion] PREG_THROW_ON_ERROR
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-132144@lists.php.net to get a copy of this message
On Thu, Jul 30, 2026 at 6:09 PM Christian Schneider <cschneid@cschneid.com> wrote: > > Am 28.07.2026 um 02:56 schrieb Osama Aldemeery <aldemeery@gmail.com>: > > The flag only changes how an error is delivered. A call does exactly the same thing with > > it or without it, byte for byte. > > The only difference is that at the end, any error the call would have recorded is > > additionally thrown, carrying the same code and > > message > > preg_last_error()/preg_last_error_msg() > > would report. > > Reading the RFC and specifically the line > > > // The detailed "Compilation failed: ..." warning is still emitted, as always. > > I assume compilation (and other?) failures will then trigger BOTH the E_WARNING and an > Exception? > > This sounds weird to me, do we have a precedent for this behavior? > I would have expected the Exception to replace the E_WARNING. > > Regards, > - Chris Hi Chris, Good question, and you're reading it right: under the flag, a compile failure emits both the E_WARNING and the exception. One clarification though...That doubling only happens for compile errors, which warn today. Execution errors on the other hand (e.g. bad UTF-8, backtrack limit, and so on) don't emit a warning at all, so those just throw. On precedent, as far as I know there isn't a precedent for somethig like this. But the reason it's currently warning-plus-exception rather than exception-instead-of-warning is because the useful detail only lives in the warning. A compile failure sets the generic PREG_INTERNAL_ERROR / `"Internal error" in the error functions, while the actual "Compilation failed: ... at offset N"` text is only in the warning. So if the exception replaced the warning today, you'd get an exception saying "Internal error" and nothing about where or why. Keeping the warning is what preserves that detail for now. It's worth mentioning though that I do think exception-instead-of-warning is the cleaner end state. But it becomes the right move once the exception can carry that detail itself, and that requires changing the message preg_last_message() reports, which is the richer compile-error reporting I've put under future scope. Until then, dropping the warning would make the flag strictly worse for debugging a bad pattern. Happy to hear if you or others see it differently. Thanks, Osama

« previous php.internals (#132144) next »