"Rowan Collins" wrote in message news:54e4fac2.7060...@gmail.com...
Tony Marston wrote on 18/02/2015 10:52:
"Rowan Collins" wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
"Rowan Collins" wrote in message news:54e1c993.1070...@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.
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
