Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82762
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
Message-ID: <54E12349.7070806@gmail.com>
Date: Sun, 15 Feb 2015 22:52:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com> <CAGa2bXaxs760ZVGharG2zZizh-+f4S+kiLv5uH4+UeDFZ4rpkA@mail.gmail.com>
In-Reply-To: <CAGa2bXaxs760ZVGharG2zZizh-+f4S+kiLv5uH4+UeDFZ4rpkA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

On 14/02/2015 00:09, Yasuo Ohgaki wrote:
> Hi Nikita,
>
> On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> As such I'm re-proposing this RFC for inclusion in PHP 7:
>>
>>      https://wiki.php.net/rfc/engine_exceptions_for_php7
>>
>> The RFC text is essentially the same as previously, with the primary
>> difference being that parse errors are now converted to exceptions as well.
>> This was previously not possible due to limitations in the compiler design.
>>
> Are E_WARNING, etc future scope?
> I briefly looked the patch. It seems it covers only engine errors.
> I suppose it's the scope of this RFC, though.
> If API is made adoptable to modules for E_WARNING, etc, it would be
> great.

Much though I'd love a more OO-approach to warnings, exceptions are not 
an appropriate mechanism for that.

A rule of thumb I rather like is that you should only throw an exception 
in a case where your best alternative, if it is not handled, is to call 
die(). Clearly, E_ERROR meets this standard, and E_WARNING does not.

There has been much talk previously that "exceptions are great because 
they include full backtraces", but there's no reason a new type of 
warning object couldn't also include those, while retaining the key 
characteristic of the default behaviour being to carry on with some 
fallback value (an empty loop, a null variable, etc) rather than to 
die('Uncaught Warning Exception!').

Regards,

-- 
Rowan Collins
[IMSoP]