Re: E_STRICT 'errors' - was Are exceptions allowed in php core?
| From: | Lester Caine | Date: | Tue, 04 Sep 2012 12:51:05 +0000 |
| Subject: | Re: E_STRICT 'errors' - was Are exceptions allowed in php core? | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-62788@lists.php.net to get a copy of this message | ||
Sherif Ramadan wrote:
On Tue, Sep 4, 2012 at 7:04 AM, Lester Caine <lester@lsces.co.uk> wrote:??? OH YES IT DOES !!! MANY times I get a a few lines of text on a white screen ... Switch off E_STRICT and everything works fine ... as it was on PHP5.2Pierre Joye wrote:E_STRICT can't crash you program. It's just like an E_WARNING or E_NTOICE level error. It's non-fatal. It does not inhibit the execution of code.And the point of YOUR comments? With E_STRICT enabled - as is the default on PHP5.4 - programs simply crash if they have not been 'converted'!How many of the major PHP user projects ARE currently strict compliant? AndThis is a development and very useful. PHP does not enforce this mode. And like any other errors, it only ends in your logs. But this has been told to you a good dozen of times in the past, and it is really getting ridiculous to have to explain that over and over.how many are still requiring E_STRICT switched off in PHP5.4?
The QUESTION is a perfectly valid one ... especially when I've just hit yet another current project that we have to make sure to disable E_STRICT when they get transferred to a PHP5.4 machine! I have no doubt a lot more will also be affected and so knowing the right answers is important. As perhaps is understanding the reason some projects are not converting code?What exactly is the question that you're posing to PHP Internals? An audit of how much code doesn't follow strict standards? Probably a lot. I've seen plenty of it in production myself and among them even the most popular PHP frameworks. Having tested Joomla on PHP 5.4 before a switch to production I recall seeing an actual drop in performance due to the sheer number of E_DEPRECATED and/or E_STRICT errors that the code produced. That is one which was white screening for me, and all I was trying to do was a favour for some one. A quick hack of the config file and we were working again, but certainly some modules in Joomla are not save when used with E_STRICT set!
However, none of that prevented the code from running (or "crashing" as you say). All you have to do is change the error_reporting directive if you chose to ignore those errors for the time being. You simply don't have display_errors on in production anyway so the worst possible outcome here is that you end up with an error log stuffed with those errors. Nothing critical here. This is not even a minor concern for most code basis that exhibit this problem to a great degree because the majority of them aren't willing to upgrade to 5.4 or have realized the problem by now and are fixing their code.The 'concern' is that ISP's are following the recommendations, and using the default production setup, so E_STRICT is on - PLEASE LEAVE IT OFF should be the standard!
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.ukWhile the preference on PHP5.4 may be to force people to comply, the reality is that this is a switch which it's more likely needs switching off in production simply because user land has no idea how to handle the problems yet. And I'll keep banging on until what is distributed from the php.net site actually works on a current default install ...The userland problem is a trivial issue. All they have to do is turn display_errors off in production as is recommended and is the default anyway. There is nothing major here to hold you back other than yourself.