Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104266
MIME-Version: 1.0
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
 <CAEZPtU5G9BABiKJnJgOCrRoaaBW-rxE=PmwWL6w2vgm1P5+-rw@mail.gmail.com>
In-Reply-To: <CAEZPtU5G9BABiKJnJgOCrRoaaBW-rxE=PmwWL6w2vgm1P5+-rw@mail.gmail.com>
Date: Thu, 7 Feb 2019 02:07:37 +0100
Message-ID: <CAFPFaMJsOYbD8JxRK6OupenQKn-fWek=b4xZ+407msm7Kv2Vzw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a8c10505814378f8"
Subject: Re: [PHP-DEV] Don't silence fatal errors
From: george.banyard@gmail.com (Girgias)

--000000000000a8c10505814378f8
Content-Type: text/plain; charset="UTF-8"

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

--000000000000a8c10505814378f8--