Hi!
Stats "@fopen()" example is perfect here, so lets say we do add this feature and people simply turn of error's entirely so that they can instead write "fopen()", they feel all good about themselves, since they handle the error locally and get a magical speed boost (noticeable or not) .. all the while they are ignoring all sorts of E_NOTICES that would indicate them that they have some serious security issues.
Actually, my point was that even if you write that code "right", only thing you achieve is slow code. It would still not be robust, unless you create if() and custom error handler for every imaginable error, it's still not more secure (since all the security works on stream level and applies to both is_readable and fopen anyway), summarily it's not better in any way but by giving you this nice feeling you "invested into nicer code". Which is totally imaginary since your code has virtually no difference from the old one except being slower. And all this because of @-phobia :)
Again, I am all for being able to totally ignore E_STRICT/E_DEPRECATED in production .. but there is a time for fixing E_NOTICES .. and that time is always!
If you think it is (and note it's not the law of the universe - I could think about dozens of use cases where E_NOTICE is useless and you *know* you don't want it) - go ahead and set you error mask to include E_NOTICE, there's nothing easier. It's not like anybody is advocating there should be only one error mask. On the contrary, I advocate flexible approach where everybody can choose the mask that fits his particular use case.
-- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
