Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82803
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <16.9B.05176.AE1C1E45@pb1.pair.com>
To: internals@lists.php.net
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com> <CAGa2bXaxs760ZVGharG2zZizh-+f4S+kiLv5uH4+UeDFZ4rpkA@mail.gmail.com> <54E12349.7070806@gmail.com>
In-Reply-To: <54E12349.7070806@gmail.com>
Date: Mon, 16 Feb 2015 10:09:41 -0000
Lines: 2
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=response
Content-Transfer-Encoding: 7bit
Importance: Normal
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: TonyMarston@hotmail.com ("Tony Marston")

"Rowan Collins"  wrote in message news:54E12349.7070806@gmail.com...
>
>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,
>

This RFC only mentions errors with object methods, so what impact would it 
have with procedural functions. For example, if fopen('nonexistantfile.txt') 
fails the return value is FALSE and an E_WARNING is generated, but it is 
difficult to trap the error message (it could be a permissions error, for 
example). Is there any plan to convert procedural functions to throw 
exceptions?

-- 
Tony Marston