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 Wednesday, March 07, 2012 12:22 AM, Gustavo Lopes wrote:
On Tue, 06 Mar 2012 17:08:07 +0100, Alan Knowles <a...@akbkhome.com>
wrote:
[...]
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).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
