# consider reverting E_ALL with E_STRICT - Thread: https://externals.io/message/58666 - Original archive: https://news-web.php.net/php.internals/58666 - Started by Alan Knowles on 2012-03-06T16:08:07+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #58666 — Alan Knowles — 2012-03-06T16:08:07+00:00 URL: https://externals.io/message/58666#58666 I just got caught on a production server with the 5.4 upgrade on debian, pretty much everything works fine, except the `E_ALL` change. I have to admit I missed the discussion where it was added, and searching for `E_ALL` or `E_STRICT` on marc is pretty difficult (it removes the E_ bit..) Anyway, this change is a bit of an bomb on the code on the first server to get hit with this, While i've never cared for `E_STRICT` (it's more like E_ANAL) - most of the warnings are pointless code tidy up's that only have pretty much zero cost/return in fixing. However, this change really kills code written by third parties, All our servers run with `E_ALL` on (eg. `E_NOTICE` is printed to end users) and we fix instantly any errors that the end users see, as they are frequently issues that should have been addressed. These applications are intra/extranet apps, not public websites. However with `E_STRICT` included we have to run around and find all the code, and change it to stuff like this: error_reporting(E_ALL & `E_STRICT` ? `E_ALL` ^ `E_STRICT` : E_ALL); Could we please revert that, and if people want an all encompasing error mode, call it E_ANAL, like it was supposed to be... Regards Alan --- ## #58667 — Reindl Harald — 2012-03-06T16:13:59+00:00 URL: https://externals.io/message/58666#58667 · In reply to: #58666 Am 06.03.2012 17:08, schrieb Alan Knowles: > However with `E_STRICT` included we have to run around and find all the code, and > change it to stuff like this: error_reporting(E_ALL & `E_STRICT` ? `E_ALL` ^ `E_STRICT` : E_ALL); > > Could we please revert that, and if people want an all encompasing error mode, call it > E_ANAL, like it was supposed to be... since 8 years on all production servers: error_reporting = `E_ALL` | `E_STRICT` the world would be a better place if code not working with this is thrown away because any developer is strongly suggested to use this in development for find small errors often makeing big problems --- ## #58669 — Pierre Joye — 2012-03-06T16:15:27+00:00 URL: https://externals.io/message/58666#58669 · In reply to: #58666 hi Alan! On a server you are supposed to use logs, not to display errors. Also if one does not like the default, he can always set the error reporting using what he likes to, per directory or globally. I see no reason to do revert what is actually a good thing. All means all, not all but this and that. Cheers, > I just got caught on a production server with the 5.4 upgrade on debian, > pretty much everything works fine, except the `E_ALL` change. > > I have to admit I missed the discussion where it was added, and searching > for `E_ALL` or `E_STRICT` on marc is pretty difficult (it removes the E_ bit..) > > Anyway, this change is a bit of an bomb on the code on the first server to > get hit with this, While i've never cared for `E_STRICT` (it's more like > E_ANAL) - most of the warnings are pointless code tidy up's that only have > pretty much zero cost/return in fixing. > > However, this change really kills code written by third parties, All our > servers run with `E_ALL` on (eg. `E_NOTICE` is printed to end users) and we fix > instantly any errors that the end users see, as they are frequently issues > that should have been addressed. These applications are intra/extranet apps, > not public websites. > > However with `E_STRICT` included we have to run around and find all the code, > and change it to stuff like this: > > error_reporting(E_ALL & `E_STRICT` ? `E_ALL` ^ `E_STRICT` : E_ALL); > > Could we please revert that, and if people want an all encompasing error > mode, call it E_ANAL, like it was supposed to be... > > Regards > Alan > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #58670 — Gustavo Lopes — 2012-03-06T16:22:00+00:00 URL: https://externals.io/message/58666#58670 · In reply to: #58666 > [...] > However with `E_STRICT` included we have to run around and find all the > code, and change it to stuff like this: > > error_reporting(E_ALL & `E_STRICT` ? `E_ALL` ^ `E_STRICT` : E_ALL); > > Could we please revert that, and if people want an all encompasing error > mode, call it E_ANAL, like it was supposed to be... Whatever the merits, this change was discussed and approved unanimously with 58 votes in favor (see https://wiki.php.net/todo/php54/vote ). There would have to be a very compelling reason to revert this change, especially in a minor version. Moreover, since you upgraded PHP 5.4, you can also change the global php.ini to exclude E_STRICT. If your applications change the error reporting level, then, if they are sane, they do it in a centralized place, which would also be easy to change. Plus, it seems odd that you're running with display_errors in production. The "users see the errors and report them" seems even odder. What a waste of their time. Why don't you just log them? You can also automatically send e-mails when these errors occur (e.g. with an error handler -- from which, btw, you can exclude `E_STRICT` errors -- or with syslog). -- Gustavo Lopes --- ## #58672 — Daniel Macedo — 2012-03-06T16:24:36+00:00 URL: https://externals.io/message/58666#58672 · In reply to: #58666 PLEASE, don't be the kind of developer that does this all over his code: > > […] Either define it once in the same place, or use the php.ini value and make sure it's proper. Here's my development/production, yours should be the same: ; Development display_errors = On display_startup_errors = On log_errors = Off ; This can now be E_ALL; as it should! error_reporting = `E_ALL` | `E_STRICT` ; Production display_errors = Off display_startup_errors = Off log_errors = On ignore_repeated_errors = On error_log = "/var/logs/php_error_log" error_reporting = `E_ALL` & ~E_DEPRECATED Cheers, ~ Daniel Macedo --- ## #58673 — Reindl Harald — 2012-03-06T16:26:17+00:00 URL: https://externals.io/message/58666#58673 · In reply to: #58670 Am 06.03.2012 17:22, schrieb Gustavo Lopes: > > > > […] > > Whatever the merits, this change was discussed and approved unanimously with 58 votes in favor (see > https://wiki.php.net/todo/php54/vote ). > There would have to be a very compelling reason to revert this change, especially in a minor version. there is no single reason to revert this bugfix the bugs were in PHP < 5.4 where ALL WAS NOT ALL which is not really smart the word ALL has a very clear definition --- ## #58674 — Ferenc Kovacs — 2012-03-06T16:28:39+00:00 URL: https://externals.io/message/58666#58674 · In reply to: #58666 > I just got caught on a production server with the 5.4 upgrade on debian, > pretty much everything works fine, except the `E_ALL` change. > > I have to admit I missed the discussion where it was added, and searching > for `E_ALL` or `E_STRICT` on marc is pretty difficult (it removes the E_ bit..) > > Anyway, this change is a bit of an bomb on the code on the first server to > get hit with this, While i've never cared for `E_STRICT` (it's more like > E_ANAL) - most of the warnings are pointless code tidy up's that only have > pretty much zero cost/return in fixing. > > However, this change really kills code written by third parties, All our > servers run with `E_ALL` on (eg. `E_NOTICE` is printed to end users) and we fix > instantly any errors that the end users see, as they are frequently issues > that should have been addressed. These applications are intra/extranet > apps, not public websites. > > However with `E_STRICT` included we have to run around and find all the > code, and change it to stuff like this: > > error_reporting(E_ALL & `E_STRICT` ? `E_ALL` ^ `E_STRICT` : E_ALL); > > Could we please revert that, and if people want an all encompasing error > mode, call it E_ANAL, like it was supposed to be... > > Regards > Alan it was proposed and voted in a "bulk" RFC, see http://www.mail-archive.com/internals@lists.php.net/msg51887.html the "Add `E_STRICT` to E_ALL" won by 58 to 0, so it was heavily supported by the voters, and that was one of the things that was already decided and commited in php6: http://www.mail-archive.com/internals@lists.php.net/msg21822.html I still think that `E_STRICT` can only serve it's purpose if our users are seeing those messages, on a relevant note, also check out this thread from Stas: http://www.mail-archive.com/internals@lists.php.net/msg52259.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #58678 — Stas Malyshev — 2012-03-06T17:19:51+00:00 URL: https://externals.io/message/58666#58678 · In reply to: #58666 Hi! > However, this change really kills code written by third parties, All our > servers run with `E_ALL` on (eg. `E_NOTICE` is printed to end users) and we You run production with display_errors enabled? Please don't do that. You have logs for that. Doesn't matter if it's intranet or not, this is not the right thing to do. Besides that, nobody forces anybody to configure error level as E_ALL. All means, well, all... If you don't want all, set the error level to something else. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #58686 — keisial@gmail.com — 2012-03-06T21:31:15+00:00 URL: https://externals.io/message/58666#58686 · In reply to: #58666 > I just got caught on a production server with the 5.4 upgrade on > debian, pretty much everything works fine, except the `E_ALL` change. > > I have to admit I missed the discussion where it was added, and > searching for `E_ALL` or `E_STRICT` on marc is pretty difficult (it > removes the E_ bit..) > > Anyway, this change is a bit of an bomb on the code on the first > server to get hit with this, While i've never cared for `E_STRICT` (it's > more like E_ANAL) - most of the warnings are pointless code tidy up's > that only have pretty much zero cost/return in fixing. > > However, this change really kills code written by third parties, All > our servers run with `E_ALL` on (eg. `E_NOTICE` is printed to end users) > and we fix instantly any errors that the end users see, as they are > frequently issues that should have been addressed. These applications > are intra/extranet apps, not public websites. > > However with `E_STRICT` included we have to run around and find all the > code, and change it to stuff like this: > > error_reporting(E_ALL & `E_STRICT` ? `E_ALL` ^ `E_STRICT` : E_ALL); error_reporting(E_ALL & ~E_STRICT); will work everywhere. You could even do a global search and replace of `E_ALL` to (E_ALL & ~E_STRICT), assuming it never appears in eg. a string. PS: I also consider `E_STRICT` a mostly helpful resource, and not using display_errors on production the sensible thing to do. --- ## #58708 — Alan Knowles — 2012-03-07T00:11:02+00:00 URL: https://externals.io/message/58666#58708 · In reply to: #58670 Sorry - top post as I can't reply to all the mails on the thread.. - display errors on. Yes, this is a business decision, 20 servers running upgraded at different times, some have less maintenance others have more.. Seriously, the chance of me even bothering to check one of those log files is pretty slim. However if the code is producing warning/notices etc. then that is likely hiding a unexpected behavior that the client will report as a bug anyway later, so it's proved over many years to be cost effective to have them display, clients report problems, and we can fix them.. They kind of like that service.... - just email them. Yes, we could get them emailed to us, but this method has worked for years, and is pretty muct failproof...., It also adds complexity to a simple solution, for example we run joomla on one server which spews crap into the logs (we ignore them as we know what I high quality piece of work that is..) however our code installed on the same server does not produce a single warning. If I had a server team, and somebody paid to watch/check logs etc.. display_errors = off would be a recommendation, but this is real life.. I do not... - change in one place That would be nice, if the client want to run quality software like joomla that spews error on the same server as our software, error reporting get's turned off in the ini setting, and we always enable it for our code in the PHP. - big vote in favour. Did anyone actually argue about the downsides of this. On the face of the question, let's just add `E_STRICT` to `E_ALL` it sounds like it's no big deal, I would have probably voted for it, without much thought. It sounds like a vote for better code. But as I discovered yesterday most of the strict errors are pedantic and completely pointless to fix, even if I did not have display errors on, they would have added a huge amount of noise to log files. - workaround for the life of me & ~E_STRICT seemed not to work yesterday.. seems to work fine now... oops.. Again, I'll survive, but it's a huge gotcha on upgrading. and should probably be promoted to this page. http://www.php.net/manual/en/migration54.incompatible.php Regards Alan > On Tue, 06 Mar 2012 17:08:07 +0100, Alan Knowles > wrote: > > > […] > > Whatever the merits, this change was discussed and approved > unanimously with 58 votes in favor (see > https://wiki.php.net/todo/php54/vote ). > There would have to be a very compelling reason to revert this change, > especially in a minor version. > > Moreover, since you upgraded PHP 5.4, you can also change the global > php.ini to exclude E_STRICT. If your applications change the error > reporting level, then, if they are sane, they do it in a centralized > place, which would also be easy to change. > > Plus, it seems odd that you're running with display_errors in > production. The "users see the errors and report them" seems even > odder. What a waste of their time. Why don't you just log them? You > can also automatically send e-mails when these errors occur (e.g. with > an error handler -- from which, btw, you can exclude `E_STRICT` errors > -- or with syslog). --- ## #58709 — John Crenshaw — 2012-03-07T01:16:20+00:00 URL: https://externals.io/message/58666#58709 · In reply to: #58708 > - display errors on. > Yes, this is a business decision, 20 servers running upgraded at different times, > some have less maintenance others have more.. > Seriously, the chance of me even bothering to check one of those log files is > pretty slim. However if the code is producing warning/notices etc. then that is > likely hiding a unexpected behavior that the client will report as a bug anyway > later, so it's proved over many years to be cost effective to have them display, > clients report problems, and we can fix them.. They kind of like that service.... > And the first time your network infrastructure has even a tiny hiccup you broadcast your database name/username/password to the whole world. Not an excellent business decision. Configuring the server to mail error logs to you isn't hard. The end result is actually faster and more reliable than waiting for a user to care enough to email you about a problem they see. > ... > > Did anyone actually argue about the downsides of this? Basically the cons come down to old generating more non-fatal errors than it did before. This is a minor BC break roughly on par with plenty of other small breaks introduced in 5.4. I do see something important in all this though. I think the documentation should explicitly state that `E_ALL` means absolutely everything, now and forever. We got into this mess in the first place because people didn't want to change the meaning of `E_ALL` when `E_STRICT` was added. We're redefining `E_ALL` now to include E_STRICT, so it means all again, but I think we need a future compatible definition that clarifies that this means all present errors, PLUS any future errors that get added for any reason. This way adding new error types would not need to be considered a BC break. John Crenshaw Priacta, Inc. --- ## #58712 — Alan Knowles — 2012-03-07T02:12:40+00:00 URL: https://externals.io/message/58666#58712 · In reply to: #58709 > And the first time your network infrastructure has even a tiny hiccup you broadcast your database name/username/password to the whole world. Not an excellent business decision. I've yet to see a php notice / warning echo out a name/password etc... - anyway these are normally not public services... - no big deal. Here's the reality, bugs exist, Users find them.. Users are really really bad at describing and reporting them "It does not work"... I can take 3-4 rounds (and a few days) of back and forth before you actually discover what the real problem is, it wastes their time (and annoys them) and yours.. Where as now. they report a screenshot or pasted error.. the problem is fixed in minutes.. with the line number and file of where the problem is.... Client is very happy, and pays quicker ;) Actually this impression that the group espouses 'do not have display errors on in production' does not apply to all situations, it may be good for your new dotcom super site, but for applications that have to work correctly and run business operations, the value proposition can be the other way round. > Configuring the server to mail error logs to you isn't hard. The end result is actually faster and more reliable than waiting for a user to care enough to email you about a problem they see. Reminds me of the backup emails, you set up warnings for the backup failing, but when the server fails, you find out the backup emails failed months ago.... Or you send out a daily backup email and everyone learns to ignore it.. It's a nice idea, but only sending me warnings/errors on this directory but not the other one and make sure it get's sent even if there is a fatal error.. get's complicated quickly. KISS is what tends to works here. > Did anyone actually argue about the downsides of this? > Basically the cons come down to old generating more non-fatal errors than it did before. This is a minor BC break roughly on par with plenty of other small breaks introduced in 5.4. > > I do see something important in all this though. I think the documentation should explicitly state that `E_ALL` means absolutely everything, now and forever. We got into this mess in the first place because people didn't want to change the meaning of `E_ALL` when `E_STRICT` was added. We're redefining `E_ALL` now to include E_STRICT, so it means all again, but I think we need a future compatible definition that clarifies that this means all present errors, PLUS any future errors that get added for any reason. This way adding new error types would not need to be considered a BC break. It is a minor BC break, when you spend an hour clearing up the mess, it's not too bad, but I had to ask, was this hour a waste of my time, did it help the code quality, and what where the benefits.. I could not see any, only the waste of time.. I think the fact is now, that most of the code I work with will have to do error_reporting(E_ALL & ~E_STRICT). I'm guessing it's unlikely that more error codes will be added that are as valueless as E_STRICT, so I think it is something to live with now..., Just in hindsight it may not have been a great decision adding it to E_ALL... Regards Alan > > John Crenshaw > Priacta, Inc. --- ## #58726 — Reindl Harald — 2012-03-07T09:49:05+00:00 URL: https://externals.io/message/58666#58726 · In reply to: #58708 Am 07.03.2012 01:11, schrieb Alan Knowles: > Sorry - top post as I can't reply to all the mails on the thread.. > > - display errors on. > Yes, this is a business decision, 20 servers running upgraded at different times, some have less maintenance others > have more.. Seriously, the chance of me even bothering to check one of those log files is pretty slim. However if > the code is producing warning/notices etc. then that is likely hiding a unexpected behavior that the client will > report as a bug anyway later, so it's proved over many years to be cost effective to have them display, clients > report problems, and we can fix them.. They kind of like that service.... it takes 10 minutes to write a script running hourly or whatever you want per cron, mailig you the error-log and reset it at the same time what you are doing is gambling that a random user will notify you about warnings not realizing that they mostly not do NEVER rely on a enduser reporting problems where this can be automated especially because php-warnings in the source code often breaks applications by have them in a form-value or in javascript parts, having them in a from-value can easily result in post them finally in a database this is not a business decision, this is poor administration --- ## #58734 — Arvids Godjuks — 2012-03-07T11:03:28+00:00 URL: https://externals.io/message/58666#58734 · In reply to: #58712 Alan Knowles You should consider the fact that some `E_STRICT` stuff can one day become `E_WARNING` or E_FATAL. For example calling a static method dynamically - I would bet that someday this thing will be moved to be a run-time fatal error and fix those if I make a mistake of doing that. Or not setting the timezone in php.ini or in the code. If I'm not mistaken the TZ guessing code was removed and now UTC time is used by default despite the server TZ set. Some unexpected results can and will come out of this. And it's a `E_STRICT` warning. So really, consider kicking developer buts to fix the issues, or one day you will find that app will not work with the new version of PHP until it's fixed.