Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94085 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72394 invoked from network); 17 Jun 2016 15:44:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jun 2016 15:44:28 -0000 Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.221 cause and error) X-PHP-List-Original-Sender: me@kelunik.com X-Host-Fingerprint: 81.169.146.221 mo4-p00-ob.smtp.rzone.de Received: from [81.169.146.221] ([81.169.146.221:25203] helo=mo4-p00-ob.smtp.rzone.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7F/39-18862-ADA14675 for ; Fri, 17 Jun 2016 11:44:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1466178264; l=4102; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=pJkBBweOG1561KaSmgVcIeHza1eVrbE6/NqYDNJkz/0=; b=nv7/KvTXzfPV1TOjMxQAETKcrK9lQNb1Udxpy5BtUXql9VK/8G05lnLxpSbTlrQM4wH MQkfnAqdsU09Q8bhRVxiqUQYwvLwnRNgdQdgtJ/P/8dzZXYsYEF1/RyEfSrYcLmP+FY8E viCTjSb2mbmF06IlJ1ytPMfTXvnf6W3I+xs= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtO3Y6 X-RZG-CLASS-ID: mo00 Received: from mail-wm0-f45.google.com ([74.125.82.45]) by smtp.strato.de (RZmta 38.6 AUTH) with ESMTPSA id f05003s5HFiNCer (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate) for ; Fri, 17 Jun 2016 17:44:23 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id v199so3200811wmv.0 for ; Fri, 17 Jun 2016 08:44:23 -0700 (PDT) X-Gm-Message-State: ALyK8tIOstNtL0qKtt9cYvtSGIYfYx2ZafQMRwRDGFXNoiVRE1ilgZrYoYRKpQHfDxdnM/sOasDd5gKRu/ipFw== X-Received: by 10.28.92.66 with SMTP id q63mr315113wmb.73.1466178263488; Fri, 17 Jun 2016 08:44:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.199.67 with HTTP; Fri, 17 Jun 2016 08:44:22 -0700 (PDT) In-Reply-To: <98f97016-066e-b5a4-8d1d-4bca179315fa@gmx.de> References: <2635b3b6-b971-9fb7-5def-26b86eafb54d@fleshgrinder.com> <98f97016-066e-b5a4-8d1d-4bca179315fa@gmx.de> Date: Fri, 17 Jun 2016 17:44:22 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Christoph Becker Cc: Alexander Lisachenko , PHP Internals Content-Type: multipart/alternative; boundary=001a114687ea92a7bf05357b3a6b Subject: Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x From: me@kelunik.com (Niklas Keller) --001a114687ea92a7bf05357b3a6b Content-Type: text/plain; charset=UTF-8 2016-06-17 11:46 GMT+02:00 Christoph Becker : > On 17.06.2016 at 10:29, Alexander Lisachenko wrote: > > > Nikita, Dmitry, ping. What do you think, shouldn't we replace all > possible > > places with Fatal Errors with correct throwing of Error exceptions? In > > this concrete case it's for "require" operator. > > > > From what I can see Error will give us more control over the file loading > > process and make it more atomic, because additional checks > > if(file_exists($file) && is_readable($file)) generate extra stat > commands, > > they are slow and not reliable, because for highload projects, we can be > in > > the situation where "if" succeeded, but the "require" will fail because > our > > file was deleted immediately after check. > > > > Code like this: > > try { > > require $fileName; > > } catch (Error $e) { > > echo "Oops, maybe deleted? " . $e; > > } > > > > is much more reliable than following, by using "include" instead of > > "require". This was suggested in https://bugs.php.net/bug.php?id=72089: > > I have re-opened this ticket. > > > if (file_exists($fileName) && is_readable($fileName)) { > > @include $fileName; // Silencing errors for the case of > race-condition, > > etc > > } > > I'm not generally against throwing exceptions from include (or several > other filesystem functions, for that matter), but the BC break has to be > considered. I am, however, still opposed to offer the ability to catch > a failing *require*. Why? --001a114687ea92a7bf05357b3a6b--