Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82939
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <37.20.01961.31113E45@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> <16.9B.05176.AE1C1E45@pb1.pair.com> <54E1C993.1070609@gmail.com>
In-Reply-To: <54E1C993.1070609@gmail.com>
Date: Tue, 17 Feb 2015 09:59:41 -0000
Lines: 1
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:54E1C993.1070609@gmail.com...
>
>Tony Marston wrote on 16/02/2015 10:09:
>> 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?
>
>As Nikita already said:
>
>> This RFC is strictly about fatal and recoverable fatal errors. Changing 
>> any
>> other error types to exceptions would be a significant
>> backwards-compatibility break.
>
>So, no, since that's currently an E_WARNING, there is no current plan to 
>change that case to an exception. If we were writing fopen() from scratch 
>now, it might be worth considering, but the BC implications of changing 
>something from non-fatal to fatal are rather drastic.
>
>That has absolutely nothing to do with OO vs procedural code, though. A 
>procedural function could well have an error condition which should be 
>fatal if unhandled, but can usefully be caught somewhere up the stack, 
>which is basically what an exception is for. Any procedural function which 
>currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to be 
>converted under the current RFC.
>
>Regards,

The reason that I mentioned this problem with fopen() - the difficulty with 
capturing the error message if it fails - is that it also exists with some 
other functions as well, so it would be nice to be able to put the function 
in  a try ..... catch block so that any and every message could be made 
available. It is quite obvious that changing fopen() to use exceptions would 
be a major BC break for all exiting applications, so my question is this:

Would it be possible to tell the function if it were being called in a try 
... catch bloc or not? If it were then throw an exception, if not then don't 
throw an exception. I realise that this might be tricky to implement, but if 
it could be it would allow the developer to choose whether he/she wanted to 
use exceptions or not instead of having the choice forced upon him/her.

Is this possible? Or am I just dreaming?

-- 
Tony Marston