Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69877
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
Message-ID: <526BC051.8030809@gmail.com>
Date: Sat, 26 Oct 2013 14:14:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
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>
In-Reply-To: <526A6BCC.3060502@php.net>
Content-Type: multipart/alternative;
 boundary="------------000306010204000406070200"
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

--------------000306010204000406070200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

-- 
Rowan Collins
[IMSoP]


--------------000306010204000406070200--