Hi! > 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.
We are discussing whether it should lead to the fatal error. I see no reason for that and declaring "it's not difficult" does not make a reason a bit clearer. There should be a reason for generating fatal error, and "this may be a bug" is not a reason enough, at least not in PHP, as long established practice in PHP clearly shows. > 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). Returning null is a legitimate function return, and there's no value that can not be legitimately returned from an existing function. Moreover, since unlike empty iterator, not calling a function is not normal (iterators can be legitimately empty, but function can not be legitimately non-existing) fatal error is a proper response to it. Of course, if we used exceptions, there could be an exception thrown instead, which is the same thing more or less. > 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. Sorry, but again I have a feeling that you are not satisfied in general with how PHP handles errors and want much more strictness there. Which is completely fine, but I must again emphasize that doing it by sneaking exceptions here and there into the core is not the right way to do it. If you want to change how PHP behaves, it should be done as a language-level principle change, and not being done by altering bits of random patches to behave how the "strict" people like and inconsistently with how the rest of PHP behaves. I would be happy to discuss it, I have a lot of issues with current error handling too, but we can not just ignore the established principles. If we have a behavior that can be used in two contexts and it is not consistent with one of them, it is not good to point out it may be consistent with another. Not throwing exception in this case is consistent with all other PHP - nothing requires that generator or iterator would throw exceptions on every problem. In fact, I do not believe any of the existing iterators throw on trying to iterate past the end. So not throwing will be consistent with everything. However, throwing will be inconsistent with foreach() usage pattern and only marginally consistent with other iterators - while they indeed throw exceptions, as far as I can see they don't do it in normal iteration scenarios, only when trying to pull something weird like accessing keys of invalid iterator or when using underlying functionality that fails. But as far as I can see you can not make any of existing SPL iterators to throw by repeatedly iterating over them. Even NoRewindIterator - which states "no rewind" in its name - does not throw when you try to repeatedly iterate over it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
