On 31/08/12 13:47, Ferenc Kovacs wrote:
It was also mentioned in that thread that we already have a bunch of
exceptions in spl, and some of the spl features should be in the core (or
it is already in the core for example IteratorAggregate).
I personally don't see why SPL is separate from core PHP, especially
since it's required. Why must the core not have OO stuff, but have
non-OO stuff?
Personally I think that OOP features should be allowed to throw Exceptions,
and I think that it would still in line with the our users expectations.
The only problem that I can think of is that for some stuff, we have both a
procedural and an oop API, but I'm not proposing turning everything into
Exceptions, but using them where appropriate.
Not for PHP 5.5 (if that's happening?), but for PHP 6 I think a lot of
things should become exceptions. I don't think that, personally, PHP's
current error handling system is sufficient for properly handling
errors. I think it's fine for warnings, notices, and deprecations. It's
well suited to that kind of thing, and for that it should be kept (along
with completely fatal core errors, where instantiating an object is
inappropriate or impossible.) And yes, I think there should be
exceptions in core PHP where appropriate
But for handling actual errors, e.g. being unable to open a file, or
failing to initialise something, Exceptions are far better suited to the
task. Especially where the error is non-fatal and you may wish to catch
it and do something else (for instance, if a file didn't exist, you
could create a new one, perhaps).
Also, I think PHP's keep-calm-and-carry-on attitude to some errors at
the moment actually makes things harder, since it will often keep going,
leaving behind some NULL value, when it would be much easier to debug if
it stopped since then you don't have a strange undefined application
state. But that's just my opinion :)
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
