Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104271
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>
 <CAEZPtU71hSzdSk7W7d_A7mbYYFRx0BRGATOdy4CtVX9k0dYwPQ@mail.gmail.com> <220843E5-03CD-4E7E-8DB5-1062C24AB8CE@cschneid.com>
In-Reply-To: <220843E5-03CD-4E7E-8DB5-1062C24AB8CE@cschneid.com>
Date: Thu, 7 Feb 2019 08:37:43 +0700
Message-ID: <CAEZPtU5At4bKVuoF8=WEff4qTCEoo3fiuLn7Dmss=_-UXJs5sQ@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Don't silence fatal errors
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Feb 7, 2019 at 3:14 PM Christian Schneider
<cschneid@cschneid.com> wrote:
>
> Am 07.02.2019 um 02:32 schrieb Pierre Joye <pierre.php@gmail.com>:
> > On Thu, Feb 7, 2019, 8:07 AM Girgias <george.banyard@gmail.com wrote:
> >> 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]
> >>
> >> [1] https://secure.php.net/manual/en/function.fopen.php
> >
> > That is one the cases I meant. Also this is a bug in the user code. I can
> > imagine doing it on purpose for performance reasons (if the file is created/deleted by other apps) tho'.
> > flock is what should be used here.
>
> Sorry if I'm missing something but would flock() help with file_get_contents() and an external program deleting a file?
>
> We have the following fields where we sometimes use @ to suppress error_log entries so they do not hide real problems not handled by our code already:
> - filesystem operations like file_get_contents() or mkdir() which can have (benevolent) races
> - json_decode() of external data (we check the validity of the data afterwards anyway)
> - DB connections which we log more detailed separately where the generic error is not interesting
>
> In general I agree with the notion of using @ as little as possible but I think it will has use cases where using error_reporting() instead would decrease code readability.
>
> Please do not remove @ ;-)

My thought that @ mainly relates to another RFC where errors/warning
are very inconsistently reported or designed (like forcing one to use
@). 8 would be a good candidate to clean that up, like the TypeError
RFC.

best,
Pierre