Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104265
MIME-Version: 1.0
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
In-Reply-To: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com>
Date: Thu, 7 Feb 2019 08:03:39 +0700
Message-ID: <CAEZPtU5G9BABiKJnJgOCrRoaaBW-rxE=PmwWL6w2vgm1P5+-rw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000060805f0581436ab8"
Subject: Re: [PHP-DEV] Don't silence fatal errors
From: pierre.php@gmail.com (Pierre Joye)

--00000000000060805f0581436ab8
Content-Type: text/plain; charset="UTF-8"

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

>

--00000000000060805f0581436ab8--