Christoph Becker <cmbecke...@gmx.de> schrieb am Sa., 18. Juni 2016, 12:34:
> 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. > Which potential BC? The only thing is a catch all handler that has already been adjusted to PHP 7. If you catch an exception you somehow promise to handle it. If you can't handle it, you should rethrow it. I don't think there will be real issues with BC, because it would have otherwise resulted in a non-handleable fatal like before. -- > Christoph M. Becker > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
