Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94101
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.169 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <CANUQDCjXfS571tguNqoQyXPwkZ-fiTGtEP+=5bee15Wc1o7yZg@mail.gmail.com>
References: <CAEbg-4Y=DaJogK+EO8dH2x59Ak_vugwXxm4M4hPw4sgtSNqmug@mail.gmail.com>
 <2635b3b6-b971-9fb7-5def-26b86eafb54d@fleshgrinder.com> <CANUQDCiYhbyUBX-NTYTJ67er2h6VoqT88zUvhePNY8Q9bSxJJw@mail.gmail.com>
 <b87d8499-7575-435d-5ab6-fc0bd629e3ae@fleshgrinder.com> <CANUQDCgQBmvDJJnA6qMMi83TXzSi97eFUJY+2vSDOkJKXuc-ew@mail.gmail.com>
 <CAEbg-4aOf1opjUHJkMPERahcG2+8yYLNDzr4NO9siY7jxtcOUw@mail.gmail.com>
 <CAEbg-4YDOfUbR=skupt1LV3+07X-ocjtHxMqpKpaqbLtku6dJg@mail.gmail.com>
 <98f97016-066e-b5a4-8d1d-4bca179315fa@gmx.de> <CANUQDCjz1RwNddF0rB_pgudKuNiZNn2R1JtDAJkG8=x1iC6BGw@mail.gmail.com>
 <ff9cc21d-6b77-2f91-6838-39d9c89f057e@gmx.de> <CANUQDCjXfS571tguNqoQyXPwkZ-fiTGtEP+=5bee15Wc1o7yZg@mail.gmail.com>
Date: Fri, 17 Jun 2016 18:08:36 -0700
Message-ID: <CANaX5neh+ZTzk5U4-zODZ7mABbLLfB-u9tP-p-PtaRqOB-gedw@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Christoph Becker <cmbecker69@gmx.de>, Alexander Lisachenko <lisachenko.it@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114064ee67792f0535831c6f
Subject: Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x
From: davey@php.net (Davey Shafik)

--001a114064ee67792f0535831c6f
Content-Type: text/plain; charset=UTF-8

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 <me@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
> >
>

--001a114064ee67792f0535831c6f--