Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45378
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.92.25 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=mgqS+uWUlxgVMWXn6PLKj4DucX5lermA/iVMti5jdHyiPgAiSuhiFRvDIJit0I72Lk
         MqgM/kuznTIv4zOP5QTo8TCLlSp+A5YPAi2Z4gzNHLCN66ahDpXvjTKou2Ym2s/czkR0
         FlGkvav6ibnVxE+sHJ7imrlqOGWB2D6asFefc=
MIME-Version: 1.0
Sender: tjerk.meesters@gmail.com
In-Reply-To: <4A932ABA.4090006@zend.com>
References: <4A92D936.2010107@zend.com> <4A931A1C.804@chiaraquartet.net>
	 <3EB779A6-0584-4368-B290-8026DEB960D3@pooteeweet.org>
	 <4A932ABA.4090006@zend.com>
Date: Tue, 25 Aug 2009 08:39:53 +0800
Message-ID: <b9defe2f0908241739u6a7978f8xa78e39c66dec4f81@mail.gmail.com>
To: Stanislav Malyshev <stas@zend.com>, Lukas Kahwe Smith <mls@pooteeweet.org>, 
	Greg Beaver <greg@chiaraquartet.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [patch] error masks
From: datibbaw@php.net (Tjerk Anne Meesters)

Hi,

Expanding on this.

In a typical project I always try to make my own code very clean by
letting it run on a staging environment with all error reporting
enabled for a while before living it; so keeping the error_reporting
enabled on the live server (and sending a daily log of caught errors)
would actually be helpful to me.

However, when it comes to external libraries, I hate to do clean-up
work there because it makes it harder to upgrade etc. With that in
mind, I'd like to be able to muffle any errors from those. Likelihood
is that those would cause errors in the main code anyway.

Not sure how it would work, technically, but I was thinking it'd be
nice to extend require*() and include*(). ;-)


On 8/25/09, Stanislav Malyshev <stas@zend.com> wrote:
> Hi!
>
>> 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.
>
> Actually, my point was that even if you write that code "right", only
> thing you achieve is slow code. It would still not be robust, unless you
> create if() and custom error handler for every imaginable error, it's
> still not more secure (since all the security works on stream level and
> applies to both is_readable and fopen anyway), summarily it's not better
> in any way but by giving you this nice feeling you "invested into nicer
> code". Which is totally imaginary since your code has virtually no
> difference from the old one except being slower. And all this because of
> @-phobia :)
>
>> 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!
>
> If you think it is (and note it's not the law of the universe - I could
> think about dozens of use cases where E_NOTICE is useless and you *know*
> you don't want it) - go ahead and set you error mask to include
> E_NOTICE, there's nothing easier. It's not like anybody is advocating
> there should be only one error mask. On the contrary, I advocate
> flexible approach where everybody can choose the mask that fits his
> particular use case.
> --
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
--
Tjerk