Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45373
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.219.216 cause and error)
Message-ID: <4A931C9F.60502@lerdorf.com>
Date: Tue, 25 Aug 2009 01:05:03 +0200
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Greg Beaver <greg@chiaraquartet.net>, 
 Stanislav Malyshev <stas@zend.com>,
 'PHP Internals' <internals@lists.php.net>
References: <4A92D936.2010107@zend.com> <4A931A1C.804@chiaraquartet.net> <3EB779A6-0584-4368-B290-8026DEB960D3@pooteeweet.org>
In-Reply-To: <3EB779A6-0584-4368-B290-8026DEB960D3@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [patch] error masks
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Lukas Kahwe Smith wrote:
> 
> On 25.08.2009, at 00:54, Greg Beaver wrote:
> 
>> 1) if a tree falls in the forest and there is no one there to hear it,
>> do we still have to put up with the performance loss?
>> 2) as long as the patch does not break any backwards compatibility
>> (error logging still works as it always did independent of error_mask,
>> user error handlers still get the same stuff), why would we care?  There
>> is a time and place for being academic about fixing things and it is
>> called development, not production.
> 
> 
> If you have bugs in production, you sure as hell want to know about ..
> and encouraging people to ignore them is a recipe for disaster.
> Stats "@fopen()" example is perfect here, so lets say we do add this
> feature and people simply turn of error's entirely so that they can
> instead write "fopen()", they feel all good about themselves, since they
> handle the error locally and get a magical speed boost (noticeable or
> not) .. all the while they are ignoring all sorts of E_NOTICES that
> would indicate them that they have some serious security issues.
> 
> Again, I am all for being able to totally ignore E_STRICT/E_DEPRECATED
> in production .. but there is a time for fixing E_NOTICES .. and that
> time is always!

I don't see how this has anything to do with the patch in question.  You
seem to be arguing that we shouldn't let people turn off E_NOTICE in
production.  How is that related to the patch?

-Rasmus