On 17.06.2016 at 17:44, Niklas Keller wrote:
> 2016-06-17 11:46 GMT+02:00 Christoph Becker <cmbecke...@gmx.de>:
>
>> 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*.
>
> Why?
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).
Or do you really prefer to be able to do
try {
require $fileName;
} catch (Error $e) {
echo "Oops, maybe deleted? " . $e;
}
functionDefinedInFileName();
and get a fatal error that function no() is undefined? I'd rather get a
fatal error that the required file couldn't be opened in the first place.
If, however, a file is not strictly required, one can (and in my
opinion, should) `include` the file. And yes, there's no absolutely
failsafe way to do this without risking a warning or using the @
operator, but that affects other filesystem functions (e.g.
file_get_contents() and fopen()) as well. 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.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
