Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94088
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
To: 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>
Message-ID: <7fa29dd7-364d-59ae-a98b-cf701b41f34d@gmail.com>
Date: Fri, 17 Jun 2016 18:58:54 +0100
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: <ff9cc21d-6b77-2f91-6838-39d9c89f057e@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x
From: rowan.collins@gmail.com (Rowan Collins)

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.



> 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.

Regards,
-- 
Rowan Collins
[IMSoP]