On 17.06.2016 at 10:29, Alexander Lisachenko wrote:
> Nikita, Dmitry, ping. What do you think, shouldn't we replace all possible
> places with Fatal Errors with correct throwing of Error exceptions? In
> this concrete case it's for "require" operator.
>
> From what I can see Error will give us more control over the file loading
> process and make it more atomic, because additional checks
> if(file_exists($file) && is_readable($file)) generate extra stat commands,
> they are slow and not reliable, because for highload projects, we can be in
> the situation where "if" succeeded, but the "require" will fail because our
> file was deleted immediately after check.
>
> Code like this:
> try {
> require $fileName;
> } catch (Error $e) {
> echo "Oops, maybe deleted? " . $e;
> }
>
> is much more reliable than following, by using "include" instead of
> "require". This was suggested in https://bugs.php.net/bug.php?id=72089:
I have re-opened this ticket.
> if (file_exists($fileName) && is_readable($fileName)) {
> @include $fileName; // Silencing errors for the case of race-condition,
> etc
> }
I'm not generally against throwing exceptions from include (or several
other filesystem functions, for that matter), but the BC break has to be
considered. I am, however, still opposed to offer the ability to catch
a failing *require*.
> Pay an attention, that we always need to put the silencing operator here to
> prevent warnings, etc. This also hides all internal errors for parsing,
> thanks to the PHP. And we can't easily detect the reason why include was
> failed. Only possible way is to register error_handler and throw an
> instance of ErrorException.
>
> But if require will throw an Error, nothing will changed, because unhandled
> Error will produce a Fatal Error, but all modern code will be able to
> handle this situation.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
