Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83166
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E9.64.22021.0E6A5E45@pb1.pair.com>
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>
	<54E4FAC2.7060200@gmail.com>
	<E9.64.22021.0E6A5E45@pb1.pair.com>
Date: Thu, 19 Feb 2015 13:57:41 +0400
Message-ID: <CA+9eiLu634OpuXVT8NnwZwitqc=S4g8UbbMj+coB4nmQcPXRQQ@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3ea3c81ff01050f6df798
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: dmitry@zend.com (Dmitry Stogov)

--001a11c3ea3c81ff01050f6df798
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston <TonyMarston@hotmail.com>
wrote:

> "Rowan Collins"  wrote in message news:54E4FAC2.7060200@gmail.com...
>
>
>> 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) {
>>
>
> The advantage is that you can obtain the reason for the error. All that
> happens with fopen() at the moment is that it returns FALSE which tells you
> that it has failed, but it does not tell you why. This is a classic example
> of the semipredicate problem for which exceptions were originally designed.
>

The main advantage is the ability to catch FATAL errors that previously
leaded to script termination and 500 response.

Thanks. Dmitry.


>
>  Having the problem be detectable in a higher scope is kind of the point
>> of exceptions.
>>
>
> So is the ability of catching an exception immediately it is thrown so
> that you can obtain the error message. Having the ability to deal with an
> exception at a higher level is only relevant if you don't deal with it
> immediately, either by design or by accident.
>
> --
> Tony Marston
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c3ea3c81ff01050f6df798--