Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45355
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 209.85.219.216 cause and error)
Cc: 'PHP Internals' <internals@lists.php.net>
Message-ID: <CCC293B8-52C8-4473-8027-6F7B32DC0C3F@prohost.org>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <4A92F13B.9000204@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 24 Aug 2009 16:32:41 -0400
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>
Subject: Re: [PHP-DEV] [patch] error masks
From: ilia@prohost.org (Ilia Alshanetsky)




On 24-Aug-09, at 3:59 PM, Stanislav Malyshev wrote:
>
>> There is very little modern code that is @ ridden like the stuff  
>> written
>
> If we discard emotional terms like "ridden" - there is such code in  
> almost every major app out there. Just search for @fopen or @include  
> or @xml or @eval - tons of examples. Ans the reason is simple -  
> people do not always want PHP to display/log errors for them.  
> Sometimes they don't care for the errors, sometimes they want to  
> handle the error by other means.

Unless your code is "ridden" or if you prefer "filled" with @ and/or  
errors the speed improvement would be next to impossible to measure  
since you'd be literally saving microseconds. You'd need to have a  
substantial chunk of your code generating errors for your  
optimizations to make a reliably measurable difference. More over, if  
the user defines an error handler, which many applications,  
frameworks, etc... do then your improvement is next to invisible in  
between the overhead of executing PHP code to process the error.

>
>> before. The way to have the engine not do the work, would be as  
>> simple as fixing the code, which is the right solution here.
>
> What you still can't see if that this code is not broken, there's  
> nothing to fix - this code is EXPLICITLY saying "do this, and if  
> there's a error - ignore it".

Vast majority of E_NOTICEs are not fixed not because people don't want  
to, but rather due to the fact that for ages PHP's default settings  
were set to ignore those errors. And E_NOTICES btw often could've let  
people know about security faults before they were abused, such as  
uninitialized variables and array keys that could be injected via  
register_globals, extract() function, etc...

Stas, my biggest issue is that you are making this configurable value  
that makes this open to abuse, rather then using 0 as default and  
matching the error message creation to error reporting settings.

ILia