Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45425
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)
To: "Richard Lynch" <ceo@l-i-e.com>
In-Reply-To: <64302.99.18.1251492424.squirrel@www.l-i-e.com>
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> <20090825030925.GA21165@panix.com> <4A93880A.9080408@zend.com> <20090825181644.GA17485@panix.com> <64302.99.18.1251492424.squirrel@www.l-i-e.com>
Message-ID: <9D3D07CF-C666-48E2-AF9A-ABD9BE31BA21@pooteeweet.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 28 Aug 2009 23:00:51 +0200
Cc: "PHP Internals List" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [patch] error masks
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 28.08.2009, at 22:47, Richard Lynch wrote:

> I must say, however, that buried in Stas' use case, 3rd party,
> not-so-clean code, and realistic pragmatic installs thereof, is buried
> the rather large problem:
>
> Many people who do such a thing, do not really do a serious
> code-review of the 3rd party code.


Right and even so .. why should using that 3rd party code make it  
sensible to flip this switch on everything? I am not really suggesting  
the following because I havent thought it out .. just an example of  
out of the box thinking we need in order to try and really address the  
root causes. Maybe we rather need some way to define error handling on  
a per directory basis. This way you could just mark this 3rd party lib  
to use a different error reporting mode. Maybe this could be expanded  
even more to also cover the ever increasing number of extensions that  
optionally throw exceptions. This way we might even be able to  
reconcile the issue that if you run PDO and one lib wants exception  
mode and the other doesnt, you need two PDO instances.

Another, again not fully thought out approach, would be to do  
something along the lines of exceptions. A magic object which can  
carry some more context but still returns true on a === false check.  
This object would of course have to be super lightweight and it should  
just contain the necessary bits in order to be able to generate the  
full error message if needed. I guess that would still probably not  
solve the performance "issue" that Stas is trying to solve, since its  
hard to imagine that such a solution would not come with so much  
overhead that it speed up anything. However it might provide for a  
better solution to deal with providing error context information  
without forcing everybody to deal with try/catch.

Anyways, so yeah I am squarely in the camp that believes that adding  
more tools to just forget about error reporting is bad mojo.

I also very much agree that many functions do not use the right  
reporting level and that several functions could probably be made to  
make it easier to avoid those reports to begin with, though yes there  
are cases where there is simply no way to avoid them.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org