Hi, Expanding on this.
In a typical project I always try to make my own code very clean by letting it run on a staging environment with all error reporting enabled for a while before living it; so keeping the error_reporting enabled on the live server (and sending a daily log of caught errors) would actually be helpful to me. However, when it comes to external libraries, I hate to do clean-up work there because it makes it harder to upgrade etc. With that in mind, I'd like to be able to muffle any errors from those. Likelihood is that those would cause errors in the main code anyway. Not sure how it would work, technically, but I was thinking it'd be nice to extend require*() and include*(). ;-) On 8/25/09, Stanislav Malyshev <s...@zend.com> wrote: > 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 > > -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
