Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83120
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
Message-ID: <54E4FAC2.7060200@gmail.com>
Date: Wed, 18 Feb 2015 20:49:06 +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> <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> <C2.98.18888.BEE64E45@pb1.pair.com>
In-Reply-To: <C2.98.18888.BEE64E45@pb1.pair.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)

Tony Marston wrote on 18/02/2015 10:52:
> "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.
>

If the exception is only thrown when the try - catch is in the same 
scope, is there really much advantage to it being an exception? When 
you're that close to the code, sticking an if ( $fh === false ) { ... } 
around it really isn't that much different from catch(IOException $e) { 
... }.

Having the problem be detectable in a higher scope is kind of the point 
of exceptions.

Regards,
-- 
Rowan Collins
[IMSoP]