Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86248
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
Message-ID: <55575DCF.50801@gmail.com>
Date: Sat, 16 May 2015 16:10:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c8nqCBGWpsqdfy+EKekOm3Cw5_zzE_nKeyLK5pzROTueg@mail.gmail.com>	<54F07FC7.8050901@php.net>	<54F0839C.3010700@seld.be>	<55052FAD.6090608@php.net>	<5505346D.7020700@php.net>	<550DA4EE.2030903@php.net>	<55410973.4010300@php.net>	<55417C64.7000707@gmail.com>	<5541B4D6.9060503@php.net>	<CAMUwpuTQ7pypMGtVvG8Uc058a3EnqTry_ss6ovZMLzg=tHGoJQ@mail.gmail.com>	<55425D7E.6010803@gmail.com>	<FE2BD464-5B2A-482B-9E84-F0CC65B52526@heroku.com>	<554D8F4D.9020903@gmail.com>	<554D90CC.3040607@php.net>	<5552E3EB.5010800@gmail.com>	<5552E494.5070401@php.net>	<CAEZPtU7=6TdFt_px6uVK_LuWQ_tdF-=fKS3S-xrRXxaS9cEvdQ@mail.gmail.com>	<5552FF58.8070807@php.net>	<CAB6YZuxf1a_rEEiuGSaYht=pwGZEunU4Hanr9c8M75pafQmocw@mail.gmail.com> <CAFMT4NoRdxUeraGn-1VtUSK_sHm5b=yAaVrOCf_vKqHTEUi6qw@mail.gmail.com>
In-Reply-To: <CAFMT4NoRdxUeraGn-1VtUSK_sHm5b=yAaVrOCf_vKqHTEUi6qw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

On 16/05/2015 15:40, Levi Morrison wrote:
> I want to talk about the BC impact of what has been discussed.
>
> Currently the meaning of this code is to catch all possible
> exceptions, because all exceptions *must* extend `\Exception`:
>
>      } catch (Exception $e) {
>
> By making some other root exception you just broke all the code that
> is *appropriately* using the catch-all variant.

That's not quite true. Currently, any code that catches all exceptions 
will still issue fatal errors for, for instance, an undeclared class. 
With a BaseException/Throwable, this behaviour will remain unchanged - 
the error messages reported will be slightly different, but they will 
still propogate to fatal errors, because the exception will be uncaught.

Now, whether catching the extra exceptions would make the code better or 
worse depends entirely on the nature of the code, but it's hard to see 
how code whose behaviour is completely unchanged can be considered 
"broken" by the proposed hierarchy.

> Please, revert all of these changes with Error and some new root
> exception and*do the right thing*  based on logical arguments.

This was the subject of a separate vote in the RFC, which passed by 39 
votes to 19. https://wiki.php.net/rfc/engine_exceptions_for_php7 The 
subject of discussion at present is the exact naming of the various 
classes/interfaces, not the general nature of the hierarchy.

Regards,

-- 
Rowan Collins
[IMSoP]