Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104270 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 36772 invoked from network); 7 Feb 2019 11:33:24 -0000 Received: from unknown (HELO mail.gna.ch) (62.12.172.119) by pb1.pair.com with SMTP; 7 Feb 2019 11:33:24 -0000 Received: from [10.0.1.55] (77-56-180-37.dclient.hispeed.ch [77.56.180.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 6F21B20F51; Thu, 7 Feb 2019 09:14:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) In-Reply-To: Date: Thu, 7 Feb 2019 09:14:58 +0100 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <220843E5-03CD-4E7E-8DB5-1062C24AB8CE@cschneid.com> References: To: Pierre Joye X-Mailer: Apple Mail (2.3445.102.3) Subject: Re: [PHP-DEV] Don't silence fatal errors From: cschneid@cschneid.com (Christian Schneider) Am 07.02.2019 um 02:32 schrieb Pierre Joye : > On Thu, Feb 7, 2019, 8:07 AM Girgias > 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] >>=20 >> [1] https://secure.php.net/manual/en/function.fopen.php >=20 > 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 @ ;-) - Chris