Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45353
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: <D3312479-4C3C-4F95-8503-FA0633FF835E@prohost.org>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <4A92EA60.6020605@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 15:40:43 -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>
Subject: Re: [PHP-DEV] [patch] error masks
From: ilia@prohost.org (Ilia Alshanetsky)


On 24-Aug-09, at 3:30 PM, Stanislav Malyshev wrote:

> Hi!
>
>> 1) Once you completely hide an error there is absolutely no trace  
>> what so ever that it has even occurred, even if its the slowdown of  
>> the native error handler being.
>
> That's the point. And how the slowdown would be useful?

Because it may force to fix the errors, rather then ignore them?

>
>> 2) Debugging code becomes that much more trickier, since a single  
>> option effectively turns off PHP's error handling completely.
>
> That's not correct. It doesn't turn off php error handling - it  
> allows you to specify which errors you handle and which not. That's  
> what error_reporting should be doing from the start, but it does  
> not. Of course, if you want notices, etc. to be displayed - display  
> them, nobody prevents you from doing so and you can see the default  
> is very permissive. But right now there's no way to save the  
> busywork that happens on errors that you *don't* want to be  
> displayed. How it helps your debugging if PHP allocates a bunch of  
> memory, spends the cycles and throws out the result without ever  
> keeping it anywhere?
>
>> As far as I can tell the only benefit of this patch is to allow  
>> error prone code to run faster by avoiding the slow down of  
>> generating error message strings when errors occurs, but the  
>> downside is abuse by people who just want errors to go away... IMHO  
>> the downside outweighs the upside.
>
> This is not correct. There is a lot of code that deliberately  
> ignores errors - with @

There is very little modern code that is @ ridden like the stuff  
written 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.

> As for "abuse" - by which you mean running code with errors disabled  
> I guess - everybody that ever ran third-party code in production  
> knows that it is an everyday reality that a lot of code out there is  
> not E_NOTICE-safe, even more is not E_STRICT/E_DEPRECATED/etc. safe.

The production value we use according to php.ini-production is E_ALL &  
~E_DEPRECATED, which means E_NOTICE will not be hidden.

> And production settings - including ones we recommend - do not  
> include reporting these errors. So they serve absolutely no useful  
> purpose but spending cycles on useless work - humans never see them,  
> nobody debugs them, only thing they do is waste time.

Well, if you are going to hide them, the no one will ever debug them,  
let alone know that they exist.