Re: Re: [patch] error masks
| From: | Ilia Alshanetsky | Date: | Tue, 25 Aug 2009 02:48:14 +0000 |
| Subject: | Re: Re: [patch] error masks | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-45381@lists.php.net to get a copy of this message | ||
Greg,
If you enable error log you would be able to identify errors, even in legacy code fairly quickly and address them as needed. The speed increase, by Stas' own admission is very minimal here, I would wager that it would be small enough that on a application generating 2-3 E_STRICTs per request you would not even be able to measure it. While saving memory and eliminating what effectively is a NOOP is a good idea, making it a configurable, user settable option, will simply lead to much abuse.
If the ultimate goal here is to save memory, why not simply set the mask to 0, which if understand Stas' original message correctly would equate its value to whatever the error reporting is set to.
On 24-Aug-09, at 10:04 PM, Greg Beaver wrote:
Ilia Alshanetsky wrote:On 24-Aug-09, at 6:54 PM, Greg Beaver wrote:Ilia, I don't see how this kind of emotional hyperbole contributes positively to the discussion. If I understand you right, you're arguing that people should never use code in production that emits errors. That is certainly the goal. It's also not always possible to do this when relying upon third-party code which may have been written for a pre-E_STRICT or a pre-E_DEPRECATED php version. What I don't understand is why you think this: <?php error_reporting(E_WARNING|E_ERROR|E_NOTICE|E_USER_WARNING|E_USER_ERROR|E_USER_NOTICE); class A { // emits an E_STRICT normally, and we waste cycles emitting an E_STRICT that is never emitted function A(){} } ?> is better than: <?php ini_set('error_mask', E_WARNING|E_ERROR|E_NOTICE|E_USER_WARNING|E_USER_ERROR|E_USER_NOTICE); class A { // just works (TM) as fast as it did in PHP 4 function A(){} } ?> IF (and a big if) no user error handler is in place, which should pass all possible errors into the error handler. If your fear is that third party people might do something horrendous like: <?php ini_set('error_mask', 0); stupidfatalerror(); ?> That's also easily solved by making it INI_SYSTEM. Greg2) as long as the patch does not break any backwards compatibility (error logging still works as it always did independent of error_mask, user error handlers still get the same stuff), why would we care? There is a time and place for being academic about fixing things and it is called development, not production.You must not have any bugs in production environment, I am very envious. :-)