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
Am 06.03.2012 17:08, schrieb Alan Knowles:
However with
E_STRICTincluded 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
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 theE_ALLchange.I have to admit I missed the discussion where it was added, and searching
forE_ALLorE_STRICTon 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 forE_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 withE_ALLon (eg.E_NOTICEis 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_STRICTincluded 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
[...]
However withE_STRICTincluded 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
Am 06.03.2012 17:22, schrieb Gustavo Lopes:
[...]
However withE_STRICTincluded 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.
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
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 addE_STRICTtoE_ALLit 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 alan@akbkhome.com
wrote:[...]
However withE_STRICTincluded 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 excludeE_STRICTerrors
-- or with syslog).
- 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.
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_ALLmeans absolutely everything, now and forever. We got into this mess in the first place because people didn't want to change the meaning ofE_ALLwhenE_STRICTwas added. We're redefiningE_ALLnow 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.
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.
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
PLEASE, don't be the kind of developer that does this all over his code:
error_reporting(E_ALL &
E_STRICT?E_ALL^E_STRICT: E_ALL);
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
I just got caught on a production server with the 5.4 upgrade on debian,
pretty much everything works fine, except theE_ALLchange.I have to admit I missed the discussion where it was added, and searching
forE_ALLorE_STRICTon 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 forE_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 withE_ALLon (eg.E_NOTICEis 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_STRICTincluded 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
internals@lists.php.net/msg51887.html" rel="nofollow" target="_blank">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:
internals@lists.php.net/msg21822.html" rel="nofollow" target="_blank">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: internals@lists.php.net/msg52259.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg52259.html
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
However, this change really kills code written by third parties, All our
servers run withE_ALLon (eg.E_NOTICEis 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
I just got caught on a production server with the 5.4 upgrade on
debian, pretty much everything works fine, except theE_ALLchange.I have to admit I missed the discussion where it was added, and
searching forE_ALLorE_STRICTon 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 forE_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 withE_ALLon (eg.E_NOTICEis 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_STRICTincluded 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 ofE_ALLto (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.