Re: Throwing an Error for require expressions in PHP7.x
| From: | Christoph Becker | Date: | Sat, 18 Jun 2016 10:34:23 +0000 |
| Subject: | Re: Throwing an Error for require expressions in PHP7.x | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-94105@lists.php.net to get a copy of this message | ||
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