Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69882
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
Message-ID: <526C0978.4030503@garfieldtech.com>
Date: Sat, 26 Oct 2013 13:27:04 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com> <52699FB5.20300@garfieldtech.com> <526A6BCC.3060502@php.net> <526BC051.8030809@gmail.com> <CAMUwpuR8XqiuM3qBZh1-Ax4ZoBnCTrFOYSPsJCL=2N--MzSCzw@mail.gmail.com>
In-Reply-To: <CAMUwpuR8XqiuM3qBZh1-Ax4ZoBnCTrFOYSPsJCL=2N--MzSCzw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: larry@garfieldtech.com (Larry Garfield)

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