Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94105
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
References: <CAEbg-4Y=DaJogK+EO8dH2x59Ak_vugwXxm4M4hPw4sgtSNqmug@mail.gmail.com>
 <2635b3b6-b971-9fb7-5def-26b86eafb54d@fleshgrinder.com>
 <CANUQDCiYhbyUBX-NTYTJ67er2h6VoqT88zUvhePNY8Q9bSxJJw@mail.gmail.com>
 <b87d8499-7575-435d-5ab6-fc0bd629e3ae@fleshgrinder.com>
 <CANUQDCgQBmvDJJnA6qMMi83TXzSi97eFUJY+2vSDOkJKXuc-ew@mail.gmail.com>
 <CAEbg-4aOf1opjUHJkMPERahcG2+8yYLNDzr4NO9siY7jxtcOUw@mail.gmail.com>
 <CAEbg-4YDOfUbR=skupt1LV3+07X-ocjtHxMqpKpaqbLtku6dJg@mail.gmail.com>
 <98f97016-066e-b5a4-8d1d-4bca179315fa@gmx.de>
 <CANUQDCjz1RwNddF0rB_pgudKuNiZNn2R1JtDAJkG8=x1iC6BGw@mail.gmail.com>
 <ff9cc21d-6b77-2f91-6838-39d9c89f057e@gmx.de>
 <7fa29dd7-364d-59ae-a98b-cf701b41f34d@gmail.com>
Message-ID: <852974b0-df1d-3942-808f-8ae1238015d2@gmx.de>
Date: Sat, 18 Jun 2016 12:34:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <7fa29dd7-364d-59ae-a98b-cf701b41f34d@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x
From: cmbecker69@gmx.de (Christoph Becker)

On 17.06.2016 at 19:58, Rowan Collins wrote:

> On 17/06/2016 17:47, Christoph Becker wrote:
>> If something is required, one cannot do without it, so there's only one
>> course of action, namely to bail out.  In my opinion, this is the least
>> surprising way to handle missing required files, especially as it always
>> has been that way (consider the potential BC break).
> 
> As Alexander has pointed out, there is no BC break, unless you are using
> an unconditional catch(Error $e) or catch(Throwable $e) - AKA the
> "Pokemon block" (gotta catch 'em all!). Any uncaught Error is still
> fatal, so amounts to zero change in behaviour.
> 
> Note that this same line of argument can be applied to many classes of
> error which became Throwable Errors in PHP 7.0, such as ParseError.

Indeed, but that was a major version – this suggestion is about PHP 7.x.

>> Frankly, I can't see a single
>> good reason to replace the fatal error with an exception for require,
>> but leave include etc. alone.  And if include would throw an exception,
>> I don't see the use of changing require at all.
> 
> Because changing include *would* be a breaking change, and in fact make
> the distinction between require and include rather pointless, because
> the whole point of include is that it *doesn't* emit anything fatal if
> the file doesn't exist.
> 
> The whole point of exceptions / throwables is that they are fatal by
> default, but handlable in a consistent manner if there is some situation
> that requires it.
> 
> As for use cases, consider that you might not be the author of the code
> containing the "require" statement - you might be including some third
> party library that doesn't something wonky, and need to be robust. Or,
> as Alexander points out, you might want to execute "finally" blocks on
> the way out, even though the application is ultimately going to crash.

Okay, I see now that there are some use cases, but would these justify
the potential BC?  I'm not sure.

-- 
Christoph M. Becker