Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104267
Return-Path: <yohgaki@ohgaki.net>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 52785 invoked from network); 7 Feb 2019 04:44:48 -0000
Received: from unknown (HELO es-i.jp) (180.42.98.130)
  by pb1.pair.com with SMTP; 7 Feb 2019 04:44:48 -0000
Received: (qmail 84624 invoked by uid 89); 7 Feb 2019 01:26:18 -0000
Received: from unknown (HELO mail-ot1-f44.google.com) (yohgaki@ohgaki.net@209.85.210.44)
  by 0 with ESMTPA; 7 Feb 2019 01:26:18 -0000
Received: by mail-ot1-f44.google.com with SMTP id k98so15621503otk.3
        for <internals@lists.php.net>; Wed, 06 Feb 2019 17:26:17 -0800 (PST)
X-Gm-Message-State: AHQUAubzZE2k5bNkatY4a1MLAqAPsSF3D3+j+MxvG5Jm48OF5zFICqNk
	iBcBnpGU11pQMcNUL563j2hdXh4/Ulh5Q9z8Ig==
X-Google-Smtp-Source: AHgI3IYwX7A/BM20ocnipMXe1RHnvvbybXZBIhWwntLhlSINCv5+Y8sRhyOV4O1g2/9FH1LJZvz45KFQ+lDCeGY6KXk=
X-Received: by 2002:a9d:69d5:: with SMTP id v21mr7516562oto.77.1549502772050;
 Wed, 06 Feb 2019 17:26:12 -0800 (PST)
MIME-Version: 1.0
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
 <CAEZPtU5G9BABiKJnJgOCrRoaaBW-rxE=PmwWL6w2vgm1P5+-rw@mail.gmail.com> <CAFPFaMJsOYbD8JxRK6OupenQKn-fWek=b4xZ+407msm7Kv2Vzw@mail.gmail.com>
In-Reply-To: <CAFPFaMJsOYbD8JxRK6OupenQKn-fWek=b4xZ+407msm7Kv2Vzw@mail.gmail.com>
Date: Thu, 7 Feb 2019 10:25:36 +0900
X-Gmail-Original-Message-ID: <CAGa2bXbnjb6A9mpPxRFxEhbVNXzv0eNE2yLDK3if_6Zvecfh3g@mail.gmail.com>
Message-ID: <CAGa2bXbnjb6A9mpPxRFxEhbVNXzv0eNE2yLDK3if_6Zvecfh3g@mail.gmail.com>
To: Girgias <george.banyard@gmail.com>
Cc: Pierre Joye <pierre.php@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004e8316058143ba00"
Subject: Re: [PHP-DEV] Don't silence fatal errors
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--0000000000004e8316058143ba00
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 7, 2019 at 10:07 AM Girgias <george.banyard@gmail.com> wrote:

> On Thu, 7 Feb 2019 at 02:03, Pierre Joye <pierre.php@gmail.com> wrote:
>
> > Good morning Nikita,
> >
> > On Tue, Nov 27, 2018, 4:43 AM 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:
> > >
> >
> >
> > I am surely missing use cases because I wonder why we need @, at all?
> >
> > Yes there are functions generating extra messages and should not, be fro.
> > PHP implementation or from external libraries (wrapping stderr to php
> > errors). All of them could be fixed.
> >
> > Best,
> > Pierre
> >
>
> The most common case which comes to mind is to suppress erros while file
> reading.
> Because even if you check a file exists it could be deleted inbetween the
> check and the
> read command. As you can see this is even written in the documentation [1]
>
> Best regards
>
> George Peter Banyard
>
> [1] https://secure.php.net/manual/en/function.fopen.php


If a developer decides to write sloppy code, then @ may be acceptable.
I wouldn't use @, though.

IMO, there should be INI switch that kills @ operator.
There is extension module for this purpose, but PHP itself should have it.
@ operator is convenient, but @ is evil and make debugging a lot harder.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--0000000000004e8316058143ba00--