Re: [PHP-DEV] [RFC] [Discussion] PREG_THROW_ON_ERROR
[email protected] (Osama Aldemeery) Thu, 30 Jul 2026 21:45:14 +0300
| Newsgroups | php.internals |
|---|---|
| Message-ID | <CABE7Eu8T+dQLggqCg68t26UrQtJ_47EUde7aWZ2vOdpD_-vi5w@mail.gmail.com> |
--0000000000009881420657d8795c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 30, 2026 at 3:22=E2=80=AFAM B.J.Scharp < [email protected]> wrote: > > On 28-07-2026 2:56 AM, Osama Aldemeery wrote: > > Hi all, > > > The exception name is settled from the pre-RFC as `\PregException` > > (thanks Tim) and the flag as `PREG_THROW_ON_ERROR`. > > From the RFC: > > The flag covers both classes of PCRE failure. > > have you considered throwing different Exception types for the two > failure types? (e.g. PregExecutionException and PregCompilationException) > > > You could have both be child classes of PregException, but in actual > fact, the second should probably be a child of LogicException, while the > former really is a RuntimeException... > > Regards, > Bernard Hi Bernard, Sorry, my last message got misformatted, so I am sending it again. Thanks again for bringing this up. As Rowan pointed out, the throwables policy settles half of it: additional exceptions must extend the extension's base or each other, not the SPL classes. So the LogicException / RuntimeException parents are out regardless. That leaves one `PregException` versus two under it (like your suggested `PregCompilationException` / `PregExecutionException`), which is a judgment call. My starting point for the whole flag is that it only changes how an error is delivered and nothing more. That is the code and the message are exactly what `preg_last_error()` and `preg_last_error_msg()` already give you. A single exception sits most naturally on top of that. There's a concrete nudge the same way....A compile failure only carries the generic `PREG_INTERNAL_ERROR` / `"Internal error"` through the error functions. The real detail (`"Compilation failed: ... at offset N"`) is in a warning, not `preg_last_error_msg()`. So a `PregCompilationException` would carry `"Internal error"` and little else until that detail is surfaced properly, which I've left as future scope. The upside of two types is letting people catch the two failure modes separately. I'm not sure how often that's needed in practice (given that `pre_last_error()` already does not differentiate between them), but I don't object if people feel it's the better design. For now I'd still favor the single `PregException`, with the door open. Thanks, Osama --0000000000009881420657d8795c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On Thu, Jul 30, 2026 at 3:22=E2=80=AFAM B.J.Scharp <<a = href=3D"mailto:[email protected]">php.list.internals= @bitwise-operators.com</a>> wrote:<br>><br>> On 28-07-2026 2:56 AM= , Osama Aldemeery wrote:<br>> =C2=A0> Hi all,<br>><br>> =C2=A0&= gt; The exception name is settled from the pre-RFC as `\PregException`<br>&= gt; =C2=A0> (thanks Tim) and the flag as `PREG_THROW_ON_ERROR`.<br>><= br>> =C2=A0From the RFC:<br>> =C2=A0> The flag covers both classes= of PCRE failure.<br>><br>> have you considered throwing different Ex= ception types for the two<br>> failure types? (<span aria-invalid=3D"spe= lling" class=3D"LI ng" style=3D"border-style:none;background:none">e.g.</sp= an> PregExecutionException and PregCompilationException)<br>><br>><br= >> You could have both be child classes of PregException, but in actual<= br>> fact, the second should probably be a child of LogicException, whil= e the<br>> former really is a RuntimeException...<br>><br>> Regard= s,<br>> Bernard<br><br><span class=3D"gmail-im">Hi Bernard,<br><br>Sorry= , my last message got misformatted, so I am sending it again.<br><br>Thanks= again for bringing this up.<br><br>As Rowan pointed out, the throwables po= licy settles half of it: additional exceptions must extend the extension= 9;s base or each other, not the SPL classes.<br>So the LogicException / Run= timeException parents are out regardless.<br><br>That leaves one `PregExcep= tion` versus two under it (like your suggested `PregCompilationException` /= `PregExecutionException`), which is a judgment call.<br></span>My starting= point for the whole flag is that it only changes how an=C2=A0<span style= =3D"color:inherit;background-color:transparent">error is delivered and noth= ing more.</span><div class=3D"gmail-HOEnZb gmail-adL"><div class=3D"gmail-i= m" style=3D"color:inherit">That <span aria-invalid=3D"grammar" class=3D"Lm = ng" style=3D"border-style:none;background:none">is the</span> code and the = message are exactly what `preg_last_error()` and `preg_last_error_msg()` al= ready give you.<br>A single exception sits most naturally on top of that.<b= r><br>There's a concrete nudge the same way....A compile failure only c= arries the generic `PREG_INTERNAL_ERROR` / `"Internal error"` thr= ough the error functions.<br>The real detail (`"Compilation failed: ..= . at offset N"`) is in a warning, not `preg_last_error_msg()`.<br>So a= `PregCompilationException` would carry `"Internal error"` and li= ttle else until that detail is surfaced properly, which I've left as fu= ture scope.<br><br>The upside of two types is letting people catch the two = failure modes separately.<br>I'm not sure how often that's needed i= n practice (given that `pre_last_error()` already does not differentiate be= tween them), but I don't object if people feel<br>it's the better d= esign.<br>For now I'd still favor the single `PregException`, with the = door open.<br><br>Thanks,<br>Osama</div></div></div> --0000000000009881420657d8795c--