Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69899
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <526D195B.9000204@gmail.com>
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com>
	<CADajX4AWmpv_mVVGvsczmKoWyqdNOd+M51cNxmuSUfSXVqrQ_w@mail.gmail.com>
	<CAF+90c8hYvWcPKNDyDYStZvnfDf3o5jzdOihQdB=rGGUMicxwQ@mail.gmail.com>
	<526D195B.9000204@gmail.com>
Date: Sun, 27 Oct 2013 16:51:26 +0100
Message-ID: <CAF+90c8xSmUuUEWJMbLghqtm5ST7UEBSRhOJW6aDi5=k9bx19w@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013a215ac85c5204e9baf4df
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: nikita.ppv@gmail.com (Nikita Popov)

--089e013a215ac85c5204e9baf4df
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Oct 27, 2013 at 2:47 PM, Rowan Collins <rowan.collins@gmail.com>wrote:

> On 26/10/2013 22:40, Nikita Popov wrote:
>
>> Reading through the mails in this thread a lot of people seem to have
>> concerns about backwards compatibility. I can see where this comes from,
>> "switch to using exceptions" certainly sounds like a seriously big BC
>> break
>> - but I don't think it actually is.
>>
>
> As I understand it, the current release process doesn't say anything about
> "big" or "major" BC breaks, but that minor releases should not break BC *at
> all*. There may be justification for relaxing that rule, but the
> justification needs to be made.


That's a misphrasing on behalf of the RFC. The question is always "how big
is the break?" not "is there a break?". The latter question doesn't even
make sense because any change to PHP - including the most trivial bugfixes
- breaks compatibility to *some* degree (well, unless the change is "fix
whitespace in foo.c") Obligatory XKCD: http://xkcd.com/1172/


>
>  First of all we should establish that fatal errors do not occur during
>> normal program execution. If you take your PHP 5.5 program and run it on
>> PHP 5.6 (with E_ERROR converted to exceptions) you will see *absolutely no
>> difference*. If you do, that means your code was previously throwing a
>> fatal error already, i.e. it didn't actually work in the first place.
>>
>
> There's a subtlety here that could be important - a script that causes
> fatal errors *in some situations* could still work in other situations.
> This is not like allowing previously invalid syntax, where an entire file
> would previously have failed to compile, these are fundamentally run-time
> behaviours, even if they *should* never happen.


My point here was that you can only see a change in cases where the program
already doesn't work correctly. If your code ran fine beforehand, it will
continue to do so. Imho that's the most important bit as far as
compatibility is concerned (to keep working code working).

I think the comment you're referring to was mine [
> http://php.markmail.org/message/n3aw4kqhclwvpsvs] so I'll expand on it a
> little.
>
> Ignoring catch-all blocks, to which BaseException is a trivial
> solution/workaround, part of the stated advantage of this change is that
> finally blocks and destructors will run if a fatal error occurs. That means
> that code is running in an application state which was previously
> impossible (except for in the very limited case of the shutdown handler).
>
> For instance, if a mis-configured deployment meant that a particular class
> could not be autoloaded, that would previously have halted all code as soon
> as an attempt was made to use it. With an exception model, however, finally
> blocks and destructors, which might themselves rely on that class in some
> subtle way, would attempt to run. Hopefully, this wouldn't cause anything
> other than a pile of further errors - it might even transparently increase
> robustness - but it's not impossible to imagine a situation where such an
> application state would corrupt data or expose a security flaw.
>
> I don't know whether to consider this a "major" or "serious" change in
> behaviour, let alone whether it would generally be "good" or "bad", but it
> is a change in behaviour.


Yes, of course behavior changes in some way - that's kind of stating the
obvious. I wouldn't be writing an RFC if I just wanted to keep everything
exactly as is. See the first paragraph again: Knowing that there is a
change doesn't help us at all (because its there by definition), the only
interesting question is how severe it is. Maybe some context will help
here: We already changed the behavior of destructors in relation to fatal
errors once - and that was during a bugfix release :)


>  As such I don't think pushing this off to PHP 6 is justified.
>>
>
> It feels like there's an assumption here that PHP 6 is a long way away.
> Rather than seeing it as pushing this feature away, it could be seen as
> pulling a major release closer. See e.g. Ferenc's suggestion to create
> separate branches for next-minor and next-major: http://php.markmail.org/*
> *message/v4gzpnfn7x6xonjs<http://php.markmail.org/message/v4gzpnfn7x6xonjs>
>

Yes, my comments are under the assumption that PHP 6 won't be there anytime
soon. Of course, if people suddenly decide that PHP 5.6 should really be
PHP 6, then there would be little to argue about ^^ Unless we have
*concrete* plans regarding PHP 6 saying "this should go into (a
hypothetical, non-existing) PHP 6" is roughly equivalent to just declining
the feature.

PHP 6 only makes sense to me if we're planning to actually do changes with
major BC impact. Not things like this RFC, but changes of basic language
semantics (like fixing the 0 == "foo" comparison and other foundational
issues).


>
>  I'd also like to point out that this RFC is a blocker for some
>> of my other proposals. In particular, I don't think that I can in good
>> conscience move the named arguments and argument unpacking RFCs forward
>> without the ability to use exceptions.
>>
>
> I'm not sure why those would particularly need exception handling any more
> than existing language features (is calling a function with a non-existent
> named parameter that different from calling a non-existent function?) but
> that's probably been discussed elsewhere. I would be interested to know
> though, hypothetically, if PHP did not have exceptions at all, do you think
> you'd feel it couldn't have named arguments until they were added?
>

Especially the named arguments RFC introduces a very big slurry of
(completely inappropriate) warnings. I don't like that and would much
prefer to properly handle things. Of course, many people don't really care
about error conditions, so I might continue those proposals even without
exceptions, but I'm not really sure about that.

Nikita

--089e013a215ac85c5204e9baf4df--