Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 209.85.216.187 cause and error)
Message-ID: <4A931A1C.804@chiaraquartet.net>
Date: Mon, 24 Aug 2009 17:54:20 -0500
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: 'PHP Internals' <internals@lists.php.net>
References: <4A92D936.2010107@zend.com>
In-Reply-To: <4A92D936.2010107@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [patch] error masks
From: greg@chiaraquartet.net (Greg Beaver)

Stanislav Malyshev wrote:
> Hi!
> 
> I've implemented a patch that allows to "mask" certain types of errors -
> i.e. make PHP engine completely ignore them. Now even if the error is
> not reported, it passes full cycle through message string creation, all
> allocations on the way, etc. even though ultimately the result of it
> will be thrown out. So I offer a way to make unwanted errors just
> disappear.
> The patch uses new directive - "error_mask", and reuses
> orig_error_reporting global (which is not used anywhere in PHP source so
> I wonder why it exists at all, but that's certainly convenient :) which
> makes it binary-compatible and fit for 5.3. Of course, in HEAD we could
> rename it.
> If the value in not 0, that's the mask which would filter out all errors
> that do not fit the mask (i.e. you could say in production that
> everything but warnings and errors should be discarded), and if the
> value is 0 then the mask is the same as error_reporting - i.e. it can be
> more dynamic and account for @, etc. and all non-reported errors will be
> discarded. Fatal errors will never be discarded.
> Alternative approach may be to just discard all non-reported errors, but
> that could be a problem with user error handlers and extension-supplied
> error callbacks, so the proposed approach is more flexible as you could
> control discarding and reporting separately.
> 
> So, what do you think?

I think it's a good idea.  Your patch does not take into account a user
error handler, however.  If present, ZEND_CAN_REPORT should evaluate to
1 to match existing behavior.

For those who are worried about losing errors, I would pose a couple of
questions:

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.

Greg