>
> If something is required, one cannot do without it, so there's only one
> course of action, namely to bail out.
What about gracefully bailing out, like showing that composer dependencies
have to be installed?
It's just like a method call. Usually you expect a return value, unless
there's an exception.
> 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 already pointed out, there's no BC break, except for catch 'em all. It's
also not surprising,
as require + parse error already throws an error instead of stopping with a
fatal error.
It's surprising that this one still fatals.
> Or do you really prefer to be able to do
>
> try {
> require $fileName;
> } catch (Error $e) {
> echo "Oops, maybe deleted? " . $e;
> }
> functionDefinedInFileName();
>
Yes, I really prefer that. Not that code exactly, but being able to write:
try {
require $config;
} catch (ParseError $e) {
}
> 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
>
