Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:45432 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4743 invoked from network); 28 Aug 2009 21:26:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Aug 2009 21:26:23 -0000 Authentication-Results: pb1.pair.com smtp.mail=ceo@l-i-e.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ceo@l-i-e.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender) X-PHP-List-Original-Sender: ceo@l-i-e.com X-Host-Fingerprint: 67.139.134.202 o2.hostbaby.com FreeBSD 4.7-5.2 (or MacOS X 10.2-10.3) (2) Received: from [67.139.134.202] ([67.139.134.202:2483] helo=o2.hostbaby.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C5/32-28995-C7B489A4 for ; Fri, 28 Aug 2009 17:26:20 -0400 Received: (qmail 15560 invoked by uid 98); 28 Aug 2009 21:26:21 -0000 Received: from localhost by o2.hostbaby.com (envelope-from , uid 1013) with qmail-scanner-2.05 (clamdscan: 0.88.7/9755. Clear:RC:1(127.0.0.1):. Processed in 0.098285 secs); 28 Aug 2009 21:26:21 -0000 Received: from localhost (HELO l-i-e.com) (127.0.0.1) by localhost with SMTP; 28 Aug 2009 21:26:21 -0000 Received: from webmail (SquirrelMail authenticated user ceo@l-i-e.com) by www.l-i-e.com with HTTP; Fri, 28 Aug 2009 16:26:21 -0500 (CDT) Message-ID: <57377.99.18.1251494781.squirrel@www.l-i-e.com> In-Reply-To: <4A98477F.80308@zend.com> References: <4A92D936.2010107@zend.com> <9E8BD3A3-8915-4492-88A9-7EA1A0CF6D86@prohost.org> <4A92DC60.2050606@zend.com> <4A92EA60.6020605@zend.com> <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> <4A98477F.80308@zend.com> Date: Fri, 28 Aug 2009 16:26:21 -0500 (CDT) To: "Stanislav Malyshev" Cc: "PHP Internals List" User-Agent: Hostbaby Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [PHP-DEV] [patch] error masks From: ceo@l-i-e.com ("Richard Lynch") On Fri, August 28, 2009 4:09 pm, Stanislav Malyshev wrote: > Hi! > >> I foresee a fair number of people who turn on error_mask, and then >> are >> defuddled by the 3rd party apps they never reviewed in the first >> place >> not behaving. > /.../ > > All that said: > > I am in favor of this patch, provided sufficient effort to be sure > the > > community knows, in advance, loud and clear, it's not a cure-all > and > > is meant only for code that can't/won't be fixed, rather than code > > that is in active development. > > As I already noted, the masking - in most cases and definitely in > recommended cases - would happen for errors that are NOT SEEN. Not > reported. Not logged. Before the patch. Which means, whatever > advantage > you seek from looking at these errors, fixing them, reviewing the > code, > doing anything related to them at all, etc., etc. - you have ALREADY > lost if when you decided not to report these errors. Without the > patch. > Before the patch. So all arguments about how wrong it is to disable > errors when errors in fact might be useful are, again, irrelevant - > they > are already disabled without the patch. I understand, really I do... And I know you understand, because you've repeated it. A lot. :-) I'm saying you have a big EDUCATION of community issue on your hands before releasing this feature, because if this many folks on @internals aren't getting it, and are making senseless knee-jerk arguments... Then you have millions of developers, and I use the term loosely, that will slaver over 300% performance boost and turn it on without having the faintest idea what it does... BREAKING the code that relies on custom error handlers, or that check $php_errormsg Those are the only sticking points for me. Let me give you a real-world pragmatic scenario: If I released "good" code with a custom error handler that gracefully and sensibly handled errors even if somebody was dumb enough to turn off error-reporting, and your patch breaks that, and then I get a zillion bug reports, I'm going to be a bit unhappy, and justifiably so. I think there more than a few developers who fit the above scenario, and the only way to avoid it is to be sure end users who install all kinds of crap next to my fabulous software [tongue firmly in cheek] and then use your new feature to shut up the bad software... I don't want to have to deal with a thousand bug reports because your patch encouraged the naive user to disable my error handling. Hope that clarifies the issue I'm forseeing... Again, I actually think you've made a good enough case for this. I just think your "patch" needs a lot of non-code changes. Better than average documentation. Changes to bug-reporting page. Comments in php.ini that clearly state that turning it "on" is BAD in general. . . . -- Some people ask for gifts here. I just want you to buy an Indie CD for yourself: http://cdbaby.com/search/from/lynch