Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45430
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.222.198 cause and error)
Message-ID: <4A984AAB.2090804@lerdorf.com>
Date: Fri, 28 Aug 2009 14:22:51 -0700
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Stanislav Malyshev <stas@zend.com>, Richard Lynch <ceo@l-i-e.com>, 
 PHP Internals List <internals@lists.php.net>
References: <4A92D936.2010107@zend.com>    <9E8BD3A3-8915-4492-88A9-7EA1A0CF6D86@prohost.org>    <4A92DC60.2050606@zend.com>    <BE47C3D9-A9FA-45CD-A004-79C8479AFDD3@prohost.org>    <4A92EA60.6020605@zend.com>    <D3312479-4C3C-4F95-8503-FA0633FF835E@prohost.org>    <4A92F13B.9000204@zend.com> <20090825030925.GA21165@panix.com>    <4A93880A.9080408@zend.com> <20090825181644.GA17485@panix.com> <64302.99.18.1251492424.squirrel@www.l-i-e.com> <4A98477F.80308@zend.com> <2E35C799-9806-4016-AEF7-0258EE64FC14@pooteeweet.org>
In-Reply-To: <2E35C799-9806-4016-AEF7-0258EE64FC14@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [patch] error masks
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Lukas Kahwe Smith wrote:
> 
> On 28.08.2009, at 23:09, Stanislav Malyshev wrote:
> 
>> As I already noted, the masking - in most cases and definitely in
>> recommended cases - would happen for errors that are NOT SEEN. Not
>> reported. Not logged. Before the patch. Which means, whatever
>> advantage you seek from looking at these errors, fixing them,
>> reviewing the code, doing anything related to them at all, etc., etc.
>> - you have ALREADY lost if when you decided not to report these
>> errors. Without the patch. Before the patch. So all arguments about
>> how wrong it is to disable errors when errors in fact might be useful
>> are, again, irrelevant - they are already disabled without the patch.
>> So far, the argument that made the most sense on this topic is that
>> using this patch would taint you with "bad mojo", I guess because when
>> you sacrifice some performance to the Gods of Unreported Errors, it's
>> all OK, but without that sacrifice, they could become enraged and
>> revenge you by... I don't know, giving you more bad mojo?
> 
> Of course we are well aware that you can choose to ignore errors even
> today. However instead of adding yet another ini setting, some of us
> feel we should rather focus on solving the real issues. That certain
> errors in certain parts of your code are unavoidable and known and that
> certain pieces of code will raise errors to the global error handler
> even though you have all the code in place to handle the issue locally.

But that isn't actually the real issue.

There will always be a reason to not report certain types of errors.
E_STRICT and E_DEPRECATED are informative development-level messages
that have no place on a production system.  They should be turned off.
The actual real problem is that our error mechanism only allows us to
turn off the final output stage, but not the actual generation of those
errors.  That is the real issue.

I do agree that having another ini switch isn't ideal, but I have
pondered this a few times and I don't see a solution that doesn't
involve some sort of configuration like that because of custom error
handlers and the php_errormsg issues.

-Rasmus