Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123934
Precedence: bulk
MIME-Version: 1.0
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <CAGBsUrfqmFqcF2bmbiftN9yO-OArAQoAAEBfQuED4jyG7N=EYw@mail.gmail.com> <OszeizyIevht0a_PnfpKBQbnQIWeGBPcOHmzGSCAXfRvwfYJZEi9ZQARIGj1XMNvWGi_pGyI0CwTaLLOWM7zyOfnlrmU5bdmgwEeQm8K5t8=@gpb.moe>
In-Reply-To: <OszeizyIevht0a_PnfpKBQbnQIWeGBPcOHmzGSCAXfRvwfYJZEi9ZQARIGj1XMNvWGi_pGyI0CwTaLLOWM7zyOfnlrmU5bdmgwEeQm8K5t8=@gpb.moe>
Date: Thu, 27 Jun 2024 12:22:39 +0200
Message-ID: <CAGBsUrcX_yJOP=B8A0gOpHH2dcvFnwdiNQW_M8wzQkvQrzT=1g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: tekiela246@gmail.com (Kamil Tekiela)

On Thu, 27 Jun 2024 at 05:57, Gina P. Banyard <internals@gpb.moe> wrote:
>
> 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

Yes, that is a better description.