Re: [RFC] Deprecations for PHP 8.4
| From: | Gina P. Banyard | Date: | Thu, 27 Jun 2024 03:57:51 +0000 |
| Subject: | Re: [RFC] Deprecations for PHP 8.4 | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-123916@lists.php.net to get a copy of this message | ||
On Wednesday, 26 June 2024 at 14:54, Kamil Tekiela <tekiela246@gmail.com> wrote:
> I think the "Deprecate passing E_USER_ERROR to trigger_error()" should
> be better explained. Why is using this constant a problem? There is a
> link to another RFC, but I can't see an explanation as to why
> E_USER_ERROR suffers the same problem as fatal errors do. From an
> average Joe's perspective, it looks fine and does the job
> https://3v4l.org/e97TO
Returning control after an E_USER_ERROR seems problematic to me in
the first place, as the condition which lead to the trigger surely
implies the current code is unable to handle the situation.
See: https://3v4l.org/7pdvO
But the issues with fatal errors are the same as explained in the
linked RFC, in that destructors (and finally blocks, etc.) are not
called. See: https://3v4l.org/J5NXF
Using exceptions instead is more robust.
Is this explanation clear enough?
If so, I will incorporate it into the RFC.
Best regards,
Gina P. Banyard