Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58669
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
Received-SPF: pass (google.com: domain of pierre.php@gmail.com designates 10.101.131.10 as permitted sender) client-ip=10.101.131.10;
MIME-Version: 1.0
In-Reply-To: <4F563667.7080006@akbkhome.com>
References: <4F563667.7080006@akbkhome.com>
Date: Tue, 6 Mar 2012 17:15:27 +0100
Message-ID: <CAEZPtU6F4Ei8Vc+g+sCWK9OCgNDpL6tC0-ccqrrAoxdnBt10PA@mail.gmail.com>
To: Alan Knowles <alan@akbkhome.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] consider reverting E_ALL with E_STRICT
From: pierre.php@gmail.com (Pierre Joye)

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,

On Tue, Mar 6, 2012 at 5:08 PM, Alan Knowles <alan@akbkhome.com> wrote:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org