Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFMT4NoA10O0D5Rt3ZFPnCJ=3bEJwKxcs9J0YuZjEMbUTQ_-MA@mail.gmail.com>
References: <CAF+90c8nqCBGWpsqdfy+EKekOm3Cw5_zzE_nKeyLK5pzROTueg@mail.gmail.com> <5541B4D6.9060503@php.net> <CAMUwpuTQ7pypMGtVvG8Uc058a3EnqTry_ss6ovZMLzg=tHGoJQ@mail.gmail.com> <55425D7E.6010803@gmail.com> <FE2BD464-5B2A-482B-9E84-F0CC65B52526@heroku.com> <554D8F4D.9020903@gmail.com> <554D90CC.3040607@php.net> <5552E3EB.5010800@gmail.com> <5552E494.5070401@php.net> <CAEZPtU7=6TdFt_px6uVK_LuWQ_tdF-=fKS3S-xrRXxaS9cEvdQ@mail.gmail.com> <5552FF58.8070807@php.net> <CAB6YZuxf1a_rEEiuGSaYht=pwGZEunU4Hanr9c8M75pafQmocw@mail.gmail.com> <CAFMT4NoRdxUeraGn-1VtUSK_sHm5b=yAaVrOCf_vKqHTEUi6qw@mail.gmail.com> <55575DCF.50801@gmail.com> <CAFMT4NpKPvRhcR+j22sWurZYnF1QJt-wj2QNsQiTo9NuCnJidg@mail.gmail.com> <55578C61.3040408@gmail.com> <CAFMT4Nq7LXR16Mz-+h5tv9x82bbcTqdGhaKWT=CuoPQSEAc-aQ@mail.gmail.com> <555796C0.2020002@gmail.com> <CAFMT4Nq9v2Jy+SDr=smUiSnVgEds9vnzNr3GVVNMyMPBu+pb-A@mail.gmail.com> <5557A5C6.5050701@gmail.com> <CAFMT4NoA10O0D5Rt3ZFPnCJ=3bEJwKxcs9J0YuZjEMbUTQ_-MA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Sun, 17 May 2015 14:10:08 +0100
To: Levi Morrison <levim@php.net>
CC: internals <internals@lists.php.net>
Message-ID: <877A3955-C72C-4DB0-9B4D-E2891EE55095@gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

On 17 May 2015 00:44:03 BST, Levi Morrison <levim@php.net> wrote:
>On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
><rowan.collins@gmail.com> wrote:
>> On 16/05/2015 20:15, Levi Morrison wrote:
>>>
>>> The difference is that as time goes on and I've written code for PHP
>7
>>> I was hit by this issue. It's an even bigger issue than even I
>>> realized during voting. How many people who voted on that issue have
>>> played with the code from both scenarios? Few, I can't guarantee it
>>> but given the historical precedent it's almost certainly true.
>>
>>
>> Can you give an example of the issue you were hit with? A sample
>program /
>> scenario, where failure to catch an EngineException caused behaviour
>that
>> was in some way worse than that under PHP 5?
>
>Here's a simplified example that illustrates one issue:
>
><?php
>
>set_error_handler(function(){
>    echo "Handled.";
>});
>
>function foo(callable $f) {}
>
>try {
>    foo("bar is not callable");
>} catch (Exception $e) {
>    echo "Caught.";
>}
>
>echo "Done.", PHP_EOL;
>
>?>
>
>In PHP 5 this prints "Handled.Done". Under PHP 7 this fails with:
>
>> Fatal error: Argument 1 passed to foo() must be callable, string
>given
>
>Note that if the TypeException had been caught by catch (Exception $e)
>the program would have still been correct. This kind of setup exists
>in PHPUnit for example; even if the test has some bad syntax or
>failure the testing harness needs to continue. There are other valid
>uses as well.

An interesting example. However, the behaviour would still have changed if TypeException was a sub-class of Exception, because it would echo "caught" rather than "handled" (a trivial difference in this trivial example, but there's no reason to assume the actual code would be the same in both cases).

The real problem here is that errors which were previously E_RECOVERABLE are now promoted to fatal when the exception is not caught. Unfortunately, I don't thick you can have both at once, because "recovering" an error returns control to wherever the error occurred, whereas an exception unwinds the stack looking for a matching catch block. So by the time an exception is flagged as uncaught, it's too late to make the error recoverable.

Of course, many of the instances of EngineException were never recoverable errors in PHP 5 (a few more would have changed that way had EngineExceptions not been adopted, e.g. https://wiki.php.net/rfc/catchable-call-to-member-of-non-object). Whichever way the hierarchy is arranged, the ability of PHPUnit to handle errors is improved, not diminished; however, it may require a one word change, under the currently accepted proposal.

Conversely, any code which handled E_RECOVERABLE but not exceptions, will now produce fatal errors, again regardless of the exception hierarchy implemented.

It's certainly a tricky issue, and the vote was far from unanimous, but I'm still not convinced of the case to reopen it.

Regards,
-- 
Rowan Collins
[IMSoP]