Re: [RFC] Exceptions in the engine

On 10/26/2013 11:26 AM, Julien Pauli wrote:

On Sat, Oct 26, 2013 at 3:14 PM, Rowan Collins <rowan.collins@gmail.com>wrote:

On 25/10/2013 14:02, Joe Watkins wrote:

On 10/24/2013 11:31 PM, Larry Garfield wrote:

As a PHP user-space developer I love this idea. However, I share the concern of others here that it could result in BC unpleasantness, even if limited to the E_FATAL and E_RECOVERABLE_FATAL use cases. I don't know off hand how various versions of Drupal would handle this. --Larry Garfield

How could anything be reliant on the behaviour of a fatal error in any meaningful way ??

I think there's an important distinction between "not breaking any backwards compatibility" and "breaking backwards compatibility in an acknowledged way having weighed the impact". A change is only 100% backwards compatible if an existing valid script would behave identically on the old and new versions, with the change only being visible if the programmer explicitly takes advantage of it. The short-hand array syntax fulfilled this requirement, to the best of my knowledge; the introduction of Traits didn't quite, because it reserved a few keywords, but that was its only impact. Throwing exceptions for things which were previously fatal errors will change the behaviour of existing scripts in several ways, some of which are the stated aims of the RFC: 1. Messages previously issuing E_RECOVERABLE_ERROR will no longer

    trigger handlers registered with set_error_handler()

2. It will no longer be possible to catch an E_RECOVERABLE_ERROR and

    continue in the same context

3. If all uses of E_RECOVERABLE_ERROR are converted to exceptions, that

    constant will become redundant, and all uses of it, e.g. in
    error_reporting() bitmasks, will become meaningless.

4. catch(Exception) blocks will pick up the errors, unless a

    BaseException is introduced

5. The handler registered with set_exception_handler() will

    (presumably) be called for such errors

6. If a BaseException *is* introduced, typehints of class Exception

    will fail for some exception objects (I spotted this noting that the
    documentation for set_exception_handler implies a callback with such
    a typehint)

7. Finally blocks and destructors will be called when an error occurs 8. As a consequence of the above, previously impossible codepaths and

    program states will become possible

9. It will become possible for multiple "fatal" errors to occur in a

    single script execution, since code will continue executing after
    the first is thrown as an exception

I don't think there can be any doubt that this change would break *some* backwards compatibility, even if a BaseException is introduced (which seems sensible) and E_RECOVERABLE_ERRORs are left untouched (which seems unfortunate). The question then becomes if it is an *acceptable* break, due to the behaviours affected being considered marginal enough to ignore - and also whether the value of having this in 5.x outweighs the cost. Don't get me wrong, I would love to see error handling in PHP cleaned up, but I'm not convinced that doing it piecemeal in non-breaking steps is either possible or desirable. I'd like to see this expanded into a fully considered mechanism which would be a fitting backbone for a major release.

+1 for the last ideas. I'm not +1 for having such a change in the 5.x branch. However, I'm full +1 to have this change + others (Warnings, Notices, etc... to exceptions), having refactored all the code ; for a 6.x branch or whatever major number it'll be. Starting trying to keep some BC, but not all, to make people half happy, but not too much nor less , is just a mistake, IMO. it will add confusion and mess in PHP, and we don't really need that :-p Your ideas are great, the patch is at an advanced stage , but such ideas and changes should definetly not go for 5.x branch. About next major, we have not decided yet which next version PHP will be. We all talked about a possible 5.6 , but if we could have a massive contribution wave, with great ideas like this one , then we could break BC, and make PHP-next a major release. Julien.Pauli

I have to agree with both of these. "It's a BC break but we've weighed it and decided it's OK" may sound good, but it's one of the key reasons that this is still the case: http://w3techs.com/technologies/details/pl-php/5/all There are more users of PHP 5.1 than there are of 5.5, and 5.4 is still less than 10% of the market. 5.3, already EOLed, only just recently surpassed 5.2 this year. This is why we (user-space developers) can't have nice things. :-) New versions of PHP have very nice things, but mass-market hosts, sysadmins, and anyone else with legacy code is extremel squeamish about upgrading to new PHP versions for fear of breaking things. That holds back the whole industry. I'd love to switch to exceptions properly in PHP, but I think it's better done as part of a for-reals switch to PHP 6, where some BC-breaking changes are allowed but cross-version compatibility is still possible. (As was the case with PHP 4->PHP5. "Well behaved" code from PHP 4.4 can still run today on 5.5, but the definition of "well behaved" wasn't necessarily known at the time of 4.2. It needs to be possible to write code that runs properly in both 5.late and 6.x, or no one will switch to 6.x) Back on topic then... +1 to engine level exceptions... in PHP 6. Which should happen sooner rather than later. --Larry Garfield