Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103528
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
In-Reply-To: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
Date: Wed, 28 Nov 2018 23:20:37 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <818C8C2C-B35C-4CFB-B23F-C97B2AD9DA94@gmail.com>
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] Don't silence fatal errors
From: claude.pache@gmail.com (Claude Pache)


> Le 26 nov. 2018 =C3=A0 22:42, Nikita Popov <nikita.ppv@gmail.com> a =
=C3=A9crit :
>=20
> Hi internals,
>=20
> 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.
>=20
> The most recent occurrence which motivated me to write this mail is
> https://bugs.php.net/bug.php?id=3D77205, but I've seen this play out =
multiple
> times already.
>=20
> 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:
>=20
> * E_ERROR
> * E_CORE_ERROR
> * E_COMPILE_ERROR
> * E_USER_ERROR
> * E_RECOVERABLE_ERROR
> * E_PARSE
>=20
> This change would have two main implications for backwards =
compatibility:
>=20
> 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 =
@.
>=20
> 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() !=3D 0 to detect silencing. This should be changed =
to
> error_reporting() & $err_no to detect whether the specific error type =
is
> silenced.
>=20
> A preliminary patch for this change is available at
> https://github.com/php/php-src/pull/3685.
>=20
> What do you think about this?
>=20
> Nikita

Although this can be viewed as an issue of the silencing operator, this =
can also be viewed as an issue of the default error handler, which =
should not blindly obey the error_reporting() directive (or the @ =
operator) in case of fatal error.

Hopefully, custom error handlers are able to scream even when they are =
asked to shut up.

My suggestion is rather to change the implementation of the default =
error handler, so that it refuses to ever sweep fatal error messages =
under the rug. Code that has legitimate reasons to silence fatal errors =
can always use a custom error handler that will obey it.

(BTW, it could be handy to have the following built-in constant:
const E_ANY_ERROR =3D E_ERROR | E_CORE_ERROR | E_COMPILE_ERROR | =
E_USER_ERROR | E_RECOVERABLE_ERROR | E_PARSE;
and ditto for warnings and notices.)

=E2=80=94Claude