Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82946
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
Message-ID: <54E32CAA.5030600@gmail.com>
Date: Tue, 17 Feb 2015 11:57:30 +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>
In-Reply-To: <37.20.01961.31113E45@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 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,
-- 
Rowan Collins
[IMSoP]