Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104188
MIME-Version: 1.0
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
In-Reply-To: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
Date: Tue, 5 Feb 2019 16:16:44 +0100
Message-ID: <CAF+90c_HaeydyEk2qyM=vxQC-_N6KKwCw_WPo1osP1Nkv99cfw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ec90f205812719ed"
Subject: Re: Don't silence fatal errors
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000ec90f205812719ed
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 26, 2018 at 10:42 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> When the silencing operator @ is used, the intention is generally to
> silence expected warnings or notices. However, it currently also silences
> fatal errors. As fatal errors also abort request execution, the result will
> often be a hard to debug white screen of death.
>
> The most recent occurrence which motivated me to write this mail is
> https://bugs.php.net/bug.php?id=77205, but I've seen this play out
> multiple times already.
>
> I would like to propose to change the behavior of @ to only silence
> warnings, notices and other low-level diagnostics, but leave fatal errors
> intake. In particular, the following should not be silenced:
>
> * E_ERROR
> * E_CORE_ERROR
> * E_COMPILE_ERROR
> * E_USER_ERROR
> * E_RECOVERABLE_ERROR
> * E_PARSE
>
> This change would have two main implications for backwards compatibility:
>
> 1. Code that legitimately wants to silence fatal errors for whatever
> reason should now use error_reporting() (or ini_set()) to do so, instead of
> @.
>
> 2. Error handlers that want to only handle non-silenced errors may have to
> be adjusted. A common pattern I found in our own tests if checks for
> error_reporting() != 0 to detect silencing. This should be changed to
> error_reporting() & $err_no to detect whether the specific error type is
> silenced.
>
> A preliminary patch for this change is available at
> https://github.com/php/php-src/pull/3685.
>
> What do you think about this?
>
> Nikita
>

I'd like to move forward with this change. I think the overall reception
here has been positive, although in the discussion some other possibilities
that avoid/reduce the BC aspect have been discussed. I think now that we
have a PHP 8 branch, it would make sense to apply this as-is. The BC break
is quite minor (compared to the other changes in PHP 8) and I think this is
the cleanest way to solve the problem, as it only changes the list of
silences errors, without introducing any new error handling concepts or
mechanisms.

Nikita

--000000000000ec90f205812719ed--