Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103531
MIME-Version: 1.0
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
 <CAJVEVOaZWJPNS9YMU=xp2oKqXe=R3ASeA9jxz0kmS-QeLR-OJA@mail.gmail.com>
In-Reply-To: <CAJVEVOaZWJPNS9YMU=xp2oKqXe=R3ASeA9jxz0kmS-QeLR-OJA@mail.gmail.com>
Date: Thu, 29 Nov 2018 10:59:22 +0100
Message-ID: <CABdc3Wp62iVR07apx2jRXLF2iQHU=WRNQaVvaiKwBODAFqUwJg@mail.gmail.com>
To: fwentish@gmail.com
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006b51fb057bcabdf0"
Subject: Re: [PHP-DEV] Don't silence fatal errors
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--0000000000006b51fb057bcabdf0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't really know if it fits here but some weeks ago I was thinking about
annotations with "@" prefix
and was considering to propose to handle @ (silence operator) similar way
as annotations, like:

$value =3D @ fopen('test.txt','rb+');

might be equivalent to:

$value =3D @SupressError(E_ALL) fopen('test.txt','rb+');

BTW This way I believe it would be easier to parse annotations with '@'
prefix in all desired places
with one branch inside parser.

As well as there will be a place to put supression error level per
function/method call
with more specific requirements, like:

$value =3D @SupressError(E_ALL ^ E_ERROR) fopen('test.txt','rb+');

Which might work as supress all errors except fatal errors.

Does that sound like a solution at all?
The developer then has full controll on what errors are supressed or not.

Sorry to bother you if it's insane and crazy idea.

czw., 29 lis 2018 o 05:44 Fwentish Aelondes <fwentish@gmail.com> napisa=C5=
=82(a):

> Breaking BC might be unnecessary if instead of changing the default
> behavior of @, you add an additional flag to error_reporting that
> enables the new behavior, something like E_UNSILENCE_FATAL. Then
> developers would only need to switch a flag in php.ini to get the old
> behavior back, instead of re-working existing code around the new
> behavior.
>
> On 11/26/18, 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 silenc=
es
> > 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=3D77205, 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 erro=
rs
> > 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 compatibilit=
y:
> >
> > 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() !=3D 0 to detect silencing. This should be changed to
> > error_reporting() & $err_no to detect whether the specific error type i=
s
> > 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
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--0000000000006b51fb057bcabdf0--