Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103541 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 73058 invoked from network); 3 Dec 2018 02:26:02 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 3 Dec 2018 02:26:02 -0000 To: internals@lists.php.net References: Date: Sun, 2 Dec 2018 23:51:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 85.230.241.5 Subject: Re: Don't silence fatal errors From: ajf@ajf.me (Andrea Faulds) Message-ID: 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. Obviously, I'd be in favour of fixing this. :) -- Andrea Faulds https://ajf.me/