Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69896
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
Message-ID: <526D195B.9000204@gmail.com>
Date: Sun, 27 Oct 2013 13:47:07 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com>	<CADajX4AWmpv_mVVGvsczmKoWyqdNOd+M51cNxmuSUfSXVqrQ_w@mail.gmail.com> <CAF+90c8hYvWcPKNDyDYStZvnfDf3o5jzdOihQdB=rGGUMicxwQ@mail.gmail.com>
In-Reply-To: <CAF+90c8hYvWcPKNDyDYStZvnfDf3o5jzdOihQdB=rGGUMicxwQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

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.

> 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.

> A misplaced catch-and-ignore block catches the fatal error and dismisses
> it. This is of course unfortunate, but it's really not more than that. It's
> an inconvenience, yes, but it does not actually break anything. Some people
> have mentioned something about code-paths becoming reachable that were
> previous not, but I don't see how that applies. If you used a try/catch
> block, then you already expect that the code-path in the catch or the code
> after it may be taken.

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.

> PHP never did Java's mistake of introducing checked exceptions, so PHP does not have a widespread
> pattern of "wrap everything with catch(Exception $e) to silence the compiler".

Actually, I would have thought checked exceptions would make catch-alls 
*less* likely, because you know for sure which exceptions need to be 
handled. In PHP, you can't rely on lower-level exceptions having been 
handled or wrapped up by libraries, so there's a possibility of e.g. a 
PDO_Exception cropping up in the middle of your business logic. But 
that's really beside the point I think - people can use catch(Exception) 
for whatever they like, and speculation about how many people will be 
affected by a BC break is not the same as understanding what the BC 
break is.

> 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

The other question is, what's the hurry? If this is introduced 
piecemeal, the result is an even more fragmented error-handling model, 
with a few slightly improved features, some of the time. And then when a 
plan is put together to overhaul error handling in general, the way 
EngineExceptions work will have to be worked into the plan, whether they 
fit or not, or a second "not very serious" BC break will be needed.

> 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?

-- 
Rowan Collins
[IMSoP]