Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.51 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <526BC051.8030809@gmail.com>
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com>
 <52699FB5.20300@garfieldtech.com> <526A6BCC.3060502@php.net> <526BC051.8030809@gmail.com>
Date: Sat, 26 Oct 2013 18:26:48 +0200
Message-ID: <CAMUwpuR8XqiuM3qBZh1-Ax4ZoBnCTrFOYSPsJCL=2N--MzSCzw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c24df6c86e3904e9a757e4
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: jpauli@php.net (Julien Pauli)

--001a11c24df6c86e3904e9a757e4
Content-Type: text/plain; charset=ISO-8859-1

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

--001a11c24df6c86e3904e9a757e4--