I'm +1 for this on require. I'd love to see exceptions for all file I/O
stuff (no more @fopen()!) but in all likelihood, we'd need a new API for
that to keep BC.
On Fri, Jun 17, 2016 at 1:32 PM, Niklas Keller <m...@kelunik.com> wrote:
> >
> > 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
> >
>
