Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103546
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=gl/qkR8w5aFTdGqdyhw555LY47nGzIuead0xtWrfw2YAuss4q4mSbFinRzyUh0
	Wg9l5ohqOV22dv/SwiOoRQSjfZZjbkRokJ42IUg5Ev3BVcbS5LhW/OpNFm25UVYq
	BbcSCrc0pzJuxMHTMDc+SLz6IWpqiUaUMZrnkbX0mab8M=;
MIME-Version: 1.0
References: <CAF+90c_wZvdgVbmdHH+7J=CLx-rivDRr4vB3=HXK3K2HSNAqMg@mail.gmail.com> <5c0461e4.1c69fb81.613f7.9f4cSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5c0461e4.1c69fb81.613f7.9f4cSMTPIN_ADDED_MISSING@mx.google.com>
Date: Mon, 3 Dec 2018 14:08:20 +0200
Message-ID: <CAJHtznwbkviTaNax9AqJ-6hXZpP5-ksV1n+k56KKvskD9Ce0ew@mail.gmail.com>
To: ajf@ajf.me, Nikita Popov <nikita.ppv@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f18b79057c1d0138"
Subject: Re: [PHP-DEV] Re: Don't silence fatal errors
From: zeev@php.net (Zeev Suraski)

--000000000000f18b79057c1d0138
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 3, 2018 at 12:51 AM Andrea Faulds <ajf@ajf.me> wrote:

> Hi Nikita,
>
> Nikita Popov wrote:
> > 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.
> It's always been bizarre to me that @ can silence fatal errors, which
> has no practical application and makes using @ to silence a lower-level
> error potentially hszardous if its targeted function can also produce a
> fatal error.
>

Well, it does have one practical application which I think we should pay
attention to if we are to change the behavior - in case of display_errors
being on (yes, nobody should have that in production, but that doesn't
change the fact that many do) - suddenly we would potentially be exposing
sensitive data to remote users - data that was previously explicitly
silenced and with this change we'd be breaking that contract.  This is not
an unlikely scenario.

OTOH I do see the value of being able to silence only non-critical
messages.  What if we do something along the lines of what somebody
proposed, and introduce another error level E_ERROR_WHILE_SILENCED or
something like that?  Folks who would want to will be able to turn it on,
and we can leave it out of E_ALL so that it would require explicit enabling.

Zeev

--000000000000f18b79057c1d0138--