Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103513
MIME-Version: 1.0
Date: Mon, 26 Nov 2018 22:42:55 +0100
Message-ID: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003ee5dd057b9838d7"
Subject: Don't silence fatal errors
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000003ee5dd057b9838d7
Content-Type: text/plain; charset="UTF-8"

 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

--0000000000003ee5dd057b9838d7--