On 17 May 2015 00:44:03 BST, Levi Morrison <le...@php.net> wrote:
>On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
><rowan.coll...@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]


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to