Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123916
Date: Thu, 27 Jun 2024 03:57:51 +0000
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
Message-ID: <OszeizyIevht0a_PnfpKBQbnQIWeGBPcOHmzGSCAXfRvwfYJZEi9ZQARIGj1XMNvWGi_pGyI0CwTaLLOWM7zyOfnlrmU5bdmgwEeQm8K5t8=@gpb.moe>
In-Reply-To: <CAGBsUrfqmFqcF2bmbiftN9yO-OArAQoAAEBfQuED4jyG7N=EYw@mail.gmail.com>
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe> <CAGBsUrfqmFqcF2bmbiftN9yO-OArAQoAAEBfQuED4jyG7N=EYw@mail.gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Wednesday, 26 June 2024 at 14:54, Kamil Tekiela <tekiela246@gmail.com> w=
rote:

> 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