Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94106
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.220 cause and error)
MIME-Version: 1.0
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> <7fa29dd7-364d-59ae-a98b-cf701b41f34d@gmail.com>
 <852974b0-df1d-3942-808f-8ae1238015d2@gmx.de>
In-Reply-To: <852974b0-df1d-3942-808f-8ae1238015d2@gmx.de>
Date: Sat, 18 Jun 2016 12:29:49 +0000
Message-ID: <CANUQDCjMf9Pkz1Hbc52M4bGeJ=jxFecuK2mTyWXV+ZG642R1Mw@mail.gmail.com>
To: Christoph Becker <cmbecker69@gmx.de>, Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=089e0122ebe23cb5d005358ca150
Subject: Re: [PHP-DEV] Throwing an Error for require expressions in PHP7.x
From: me@kelunik.com (Niklas Keller)

--089e0122ebe23cb5d005358ca150
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Christoph Becker <cmbecker69@gmx.de> schrieb am Sa., 18. Juni 2016, 12:34:

> On 17.06.2016 at 19:58, Rowan Collins wrote:
>
> > On 17/06/2016 17:47, Christoph Becker wrote:
> >> If something is required, one cannot do without it, so there's only on=
e
> >> course of action, namely to bail out.  In my opinion, this is the leas=
t
> >> surprising way to handle missing required files, especially as it alwa=
ys
> >> has been that way (consider the potential BC break).
> >
> > As Alexander has pointed out, there is no BC break, unless you are usin=
g
> > an unconditional catch(Error $e) or catch(Throwable $e) - AKA the
> > "Pokemon block" (gotta catch 'em all!). Any uncaught Error is still
> > fatal, so amounts to zero change in behaviour.
> >
> > Note that this same line of argument can be applied to many classes of
> > error which became Throwable Errors in PHP 7.0, such as ParseError.
>
> Indeed, but that was a major version =E2=80=93 this suggestion is about P=
HP 7.x.
>
> >> 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.
> >
> > Because changing include *would* be a breaking change, and in fact make
> > the distinction between require and include rather pointless, because
> > the whole point of include is that it *doesn't* emit anything fatal if
> > the file doesn't exist.
> >
> > The whole point of exceptions / throwables is that they are fatal by
> > default, but handlable in a consistent manner if there is some situatio=
n
> > that requires it.
> >
> > As for use cases, consider that you might not be the author of the code
> > containing the "require" statement - you might be including some third
> > party library that doesn't something wonky, and need to be robust. Or,
> > as Alexander points out, you might want to execute "finally" blocks on
> > the way out, even though the application is ultimately going to crash.
>
> Okay, I see now that there are some use cases, but would these justify
> the potential BC?  I'm not sure.
>

Which potential BC? The only thing is a catch all handler that has already
been adjusted to PHP 7.

If you catch an exception you somehow promise to handle it. If you can't
handle it, you should rethrow it.

I don't think there will be real issues with BC, because it would have
otherwise resulted in a non-handleable fatal like before.

--
> Christoph M. Becker
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0122ebe23cb5d005358ca150--