Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58708
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain akbkhome.com designates 202.81.246.113 as permitted sender)
Message-ID: <4F56A796.9000109@akbkhome.com>
Date: Wed, 07 Mar 2012 08:11:02 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: internals@lists.php.net
References: <4F563667.7080006@akbkhome.com> <op.warbqyfjidpuyk@slws007.slhq.int>
In-Reply-To: <op.warbqyfjidpuyk@slws007.slhq.int>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] consider reverting E_ALL with E_STRICT
From: alan@akbkhome.com (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....

- 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 <alan@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).
>