Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45424
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender)
Message-ID: <64302.99.18.1251492424.squirrel@www.l-i-e.com>
In-Reply-To: <20090825181644.GA17485@panix.com>
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>
Date: Fri, 28 Aug 2009 15:47:04 -0500 (CDT)
To: "PHP Internals List" <internals@lists.php.net>
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] [patch] error masks
From: ceo@l-i-e.com ("Richard Lynch")

Personally, I generally prefer log_errors and E_ALL in production.

That said, there have been cases where it really wouldn't make much
sense to log the errors on a web tier with many nodes.

Or, at least, it didn't make sense to *just* log the errors.

But I digress.

I believe Stas has made a good pragamatic argument for a reasonable
use case that improves performance in common enough usage by people
who do know what they are doing, and want/need the performance gain.

The detractors have, largely, not been cogent, to be frank.

The most reasonable have been to be careful not to rush this through
without considering its effects on cases like X.  To which Stas says,
"Of course not.  Don't use it in case X."

I must say, however, that buried in Stas' use case, 3rd party,
not-so-clean code, and realistic pragmatic installs thereof, is buried
the rather large problem:

Many people who do such a thing, do not really do a serious
code-review of the 3rd party code.

They toss it on there, it works, and they move on to the next task.

I foresee a fair number of people who turn on error_mask, and then are
defuddled by the 3rd party apps they never reviewed in the first place
not behaving.

Certainly, they are getting what they deserve, in some lights.

But, to remain pragmatic, the PHP Dev Team has to be ready for an
onslaught of issues and bug reports about 3rd party software in this
state.

As an example, before this feature rolls out, I'd have to suggest that
the bug reporting page include it in things to turn OFF before a bug
report is accepted, in that section about 3rd party extensions.

This is just one example off the top of my head.  I'm pretty sure
there are more ramifications that go well beyond the code-based
discussion so far.

All that said:
I am in favor of this patch, provided sufficient effort to be sure the
community knows, in advance, loud and clear, it's not a cure-all and
is meant only for code that can't/won't be fixed, rather than code
that is in active development.

In fact, I'd suggest that using error_mask should emit an E_STRICT,
*not* suppressed by error_mask, before it kicks in. :-)

-- 
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch