Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69857
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
Message-ID: <526982E2.1050401@gmail.com>
Date: Thu, 24 Oct 2013 21:28:18 +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> <CADajX4AWmpv_mVVGvsczmKoWyqdNOd+M51cNxmuSUfSXVqrQ_w@mail.gmail.com>
In-Reply-To: <CADajX4AWmpv_mVVGvsczmKoWyqdNOd+M51cNxmuSUfSXVqrQ_w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

On 24/10/2013 19:01, Adam Harvey wrote:
> On 24 October 2013 10:41, Nikita Popov <nikita.ppv@gmail.com> wrote:
>> I'd like to propose an RFC, which allows the use of exceptions within the
>> engine and also allows changing existing fatal errors to exceptions
> I love the idea — unified error and exception handling would be a huge
> win both for simplifying code bases and teaching new developers — but
> I don't see any possible way we could do this in a 5.x release. The BC
> issues are just too great, and too many people rely heavily on the
> set_error_handler() behaviour that we have today.

FWIW, as an outsider, I'd tend to agree with this. It might be possible 
to implement this in a backwards compatible way, but there would be a 
lot of details to consider. More importantly, if this isn't a big enough 
change to warrant a major release, what is? The more major features make 
it into 5.x, with BC carefully maintained, the more it feels like 5.x 
will go on living indefinitely, with the implication - according to the 
current release process - that deprecated or broken APIs will "never" be 
removed or fixed.

> I wouldn't selectively convert errors to exceptions as the "policy changes" section suggests
> — let's do them all and be done with it

This I agree with even more strongly, but I also don't think this should 
be a one-to-one mapping of the existing errors. From what I can see, the 
current patch uses neither sub-classes nor exception codes, just the 
existing message strings. This seems like a massive missed opportunity - 
a big part of exception handling is choosing which exceptions to handle, 
and at the moment, the only way to detect what error was thrown is by 
string matching, including accounting for substituted parts.

It would also be nice to consider changing the handling of non-fatals as 
well, although I'm not quite sure how they should work. Again, there is 
currently no way to detect the "type" of a warning or notice, only its 
severity; nor is there an easy way to have different handlers for 
different severities. Those severities can also be pretty arbitrary: 
e.g. an undefined constant issues an E_NOTICE, but a class constant is 
E_ERROR, presumably for historical reasons, which would matter less if 
there were additional meta-data to recognise them by.

The other rather more blue-sky thought I had is that it would be nice to 
scope error-handling "lexically", in the sense of all functions in a 
particular included library being under a different error-handling 
regime from the outer program, reagardless of execution order. There are 
old modules in PEAR which work fine with current versions of PHP, but 
emit lots of E_DEPRECATED or E_NOTICE messages; what I really want to 
say is "yes, our use of that whole module is deprecated, we're not going 
to clean it up, but our own code should be nice and clean".

Regards,

-- 
Rowan Collins
[IMSoP]