Em 2012-09-03 23:51, Stas Malyshev escreveu:
I've replied here:
http://www.mail-archive.com/internals@lists.php.net/msg60706.html
I have a feeling you're concocting a very far-reaching scenarios and
making a lot of unbased assumptions there to arrive to pre-defined
conclusions. Any programming error can cost a business money, and any
problem can be fitted with scenario when it leads to blowing up whole
world in the flames of global catastrophe, given enough imagination
and
wild enough assumptions.
Sure. It's all a matter of degree. Like I said in the other reply, an
accidental null -> 0 conversion can cause severe silent (no errors)
problems, yet we do such automatic conversions. The question is what's
to be gained vs. the additional risk. And there is little to no benefit
in a model where rewinding a closed iterator is allowed, so the
threshold for acceptable risk is very low. This is not a difficult case
at all, IMHO.
However, I do not see any technical reason - not involving
far-reaching
assumptions following from nowhere - that require repeated generation
produce a fatal error.
There is no strict technical reason for most fatals in PHP too. Except
maybe parser errors, you usually can abstain from doing whatever action
would cause the fatal instead of raising the fatal. Calling function
that does not exist or abstract method? Return NULL (like an invalid
call btw).
So far all the explanations seem to be to the
tune of "because it's so bad!" but I don't see how it's worse than
any
other fault - such as failing to open the file, database returning no
results because of wrong query, etc. We do not produce fatal errors
on
all of these cases - in fact, we produce fatal errors only when we
know
there's no reasonable way to go on. I still do not see why just
returning empty iterator with suitable warning does not fit the
pattern
of all exceptional situations we have in PHP that are handled in a
similar way.
The examples you do are not comparable. 1) They involve parts that the
PHP programmer does not control and 2) they provide ways to detect the
failure.
For foreach() specifically, for example, you can put there
invalid - non-iterable - value, and it won't be a fatal error. Why
non-iterable value from generator should be a fatal error?
I think it makes sense to treat it exactly like foreach() treats
non-iterable values.
IMO, this is perhaps your strongest argument. But 1) that was a bad
idea, 2) we're not really talking about the behavior of foreach(), we're
talking about the behavior of specific methods that may or may not be
called in the context of a foreach, in a hierarchy where exception
throwing is well established. So it's not really analogous.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
