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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
