Lukas Kahwe Smith wrote: > > On 28.08.2009, at 23:09, Stanislav Malyshev wrote: > >> As I already noted, the masking - in most cases and definitely in >> recommended cases - would happen for errors that are NOT SEEN. Not >> reported. Not logged. Before the patch. Which means, whatever >> advantage you seek from looking at these errors, fixing them, >> reviewing the code, doing anything related to them at all, etc., etc. >> - you have ALREADY lost if when you decided not to report these >> errors. Without the patch. Before the patch. So all arguments about >> how wrong it is to disable errors when errors in fact might be useful >> are, again, irrelevant - they are already disabled without the patch. >> So far, the argument that made the most sense on this topic is that >> using this patch would taint you with "bad mojo", I guess because when >> you sacrifice some performance to the Gods of Unreported Errors, it's >> all OK, but without that sacrifice, they could become enraged and >> revenge you by... I don't know, giving you more bad mojo? > > Of course we are well aware that you can choose to ignore errors even > today. However instead of adding yet another ini setting, some of us > feel we should rather focus on solving the real issues. That certain > errors in certain parts of your code are unavoidable and known and that > certain pieces of code will raise errors to the global error handler > even though you have all the code in place to handle the issue locally.
But that isn't actually the real issue. There will always be a reason to not report certain types of errors. E_STRICT and E_DEPRECATED are informative development-level messages that have no place on a production system. They should be turned off. The actual real problem is that our error mechanism only allows us to turn off the final output stage, but not the actual generation of those errors. That is the real issue. I do agree that having another ini switch isn't ideal, but I have pondered this a few times and I don't see a solution that doesn't involve some sort of configuration like that because of custom error handlers and the php_errormsg issues. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
