Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Stanislav Malyshev <stas@zend.com>,
 jani.taskinen@iki.fi,
 Ilia Alshanetsky <ilia@prohost.org>,
 'PHP Internals' <internals@lists.php.net>
Message-ID: <D228D369-1B36-4F7B-8FBF-8CFB63AB8804@pooteeweet.org>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
In-Reply-To: <4A930D54.6050705@lerdorf.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: Tue, 25 Aug 2009 00:11:47 +0200
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> <CCC293B8-52C8-4473-8027-6F7B32DC0C3F@prohost.org> <4A92FFA8.1060401@zend.com> <4A9304FC.2000906@sci.fi> <4A930956.9070709@zend.com> <250F0E93-D6F2-490F-9129-598AC6E96500@pooteeweet.org> <4A930D54.6050705@lerdorf.com>
Subject: Re: [PHP-DEV] [patch] error masks
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 24.08.2009, at 23:59, Rasmus Lerdorf wrote:

> Lukas Kahwe Smith wrote:
>>
>> On 24.08.2009, at 23:42, Stanislav Malyshev wrote:
>>
>>> Hi!
>>>
>>>> Quite boring to read this thread where two persons argue about
>>>> something abstract. Stas, can you give a real life example where  
>>>> your
>>>> patch is necessary..?
>>>
>>> Any code where you either use @ or error_reporting which is not -1
>>> would benefit from it by not processing errors that go nowhere. I  
>>> just
>>> looked at Zend Framework - with is pretty clean with regard to
>>> E_NOTICE/E_STRICT problems - and @ is used in dozens of classes
>>> around. The speedup would be probably not very big for whole RL
>>> application, but it's a 10-line patch, and little things help too.
>>
>>
>> well a few of those places would probably be fixable, by providing
>> functions to check beforehand if calling the final function would  
>> cause
>> an error. but that if course would add more overhead, but would  
>> still be
>> the "cleaner" solution.
>>
>> overall i am not so convinced about the ignoring approach. as for
>> E_STRICT .. that shouldnt become less of an issue now that we have
>> E_DEPRECATED .. but i guess that just means that in the future people
>> will complain about E_DEPRECATED ..
>>
>> anyways to me both E_STRICT and E_DEPRECATED are development tools  
>> that
>> can be totally ignored in production. however E_NOTICE should not  
>> occur
>> in production and we shouldnt encourage people to make them disappear
>> entirely.
>
> Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
> E_NOTICE, whatever, all cause a performance hit even if the
> error_reporting level is such that they will never show up anywhere.
> That's what this patch is trying to address.  To write optimal code,
> they have to be entirely clean of all messages including E_DEPRECATED
> and E_STRICT.
>

right .. what i was trying to say was that i can see value in being  
able to hide  E_DEPRECATED and E_STRICT, but the error stuff shouldnt  
be hidden that way. users should either display or log their E_NOTICES  
and fix them!

regards,
Lukas Kahwe Smith
mls@pooteeweet.org