Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83040
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <C2.98.18888.BEE64E45@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> <37.20.01961.31113E45@pb1.pair.com> <54E32CAA.5030600@gmail.com>
In-Reply-To: <54E32CAA.5030600@gmail.com>
Date: Wed, 18 Feb 2015 10:52:20 -0000
Lines: 7
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:54E32CAA.5030600@gmail.com...
>
>Tony Marston wrote on 17/02/2015 09:59:
>> "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?
>
>The point of exceptions is that they don't have to be caught in the current 
>scope. So is the below fopen() call "in a try ... catch block" for the 
>purposes of that check, or not? If putting try { ... } around an entire 
>application caused all calls to fopen(), in every library it used, to stop 
>returning false, you'd have exactly the same BC issue as just changing it 
>permanently.
>
>
>function foo() {
>try
>{
>$data = load_data();
>}
>catch ( ... ) { ... }
>}
>
>function load_data() {
>$fh = fopen(...);
>...
>}
>
>So no, I'm afraid it's probably not possible.
>
>Regards,

Could it be restricted to the current scope? In your example the call to 
fopen() exists in the load_data() function and is not in a try ... catch 
block within *that* function, so the fact that the call to load_data() is 
within a try ... catch block should be irrelevant as it is in a different 
scope.

-- 
Tony Marston