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) {
... }.
Having the problem be detectable in a higher scope is kind of the point
of exceptions.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
