Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6549 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90043 invoked by uid 1010); 18 Dec 2003 17:45:31 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 89958 invoked from network); 18 Dec 2003 17:45:30 -0000 Received: from unknown (HELO mail.info-link.net) (65.122.208.20) by pb1.pair.com with SMTP; 18 Dec 2003 17:45:30 -0000 Received: from info-link.net (spooler.info-link.net [65.122.208.6]) by mail.info-link.net (8.12.10/8.12.10) with ESMTP id hBIHjOH5032139; Thu, 18 Dec 2003 11:45:25 -0600 Message-ID: <3FE1E7B4.14CE511E@info-link.net> Date: Thu, 18 Dec 2003 11:45:24 -0600 Organization: Info Link Inc. X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Christian Schneider CC: Daniel Convissor , PHP Internals List References: <20031218124303.18e22274.paj@pearfr.org> <20031218140527.GA26390@panix.com> <3FE1D96B.3090308@chiaraquartet.net> <20031218170305.GA16670@panix.com> <3FE1DEF9.4060705@chiaraquartet.net> <20031218171530.GA17635@panix.com> <3FE1E318.3060004@cschneid.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.6; VAE 6.23.0.1; VDF 6.23.0.14 Subject: Re: [PHP-DEV] B3, pear segfault, and msgs about deprecated From: brad@info-link.net (Brad Fisher) Personally, I both like and dislike this behavior. I like it for debugging purposes, since it allows me full control over whether I ignore error_reporting level or perhaps just log disabled levels instead of displaying them, etc. On the other hand, there is a minor performance issue, but if you write your code to not emit E_NOTICES, it shouldn't really be a big problem. -Brad Christian Schneider wrote: > Daniel Convissor wrote: > > It's the custom error handler in pearcmd.php. PHP doesn't pay attention > > to any error_reporting() settings when a custom error handler is > > established. Then, error_handler() doesn't account for the new warning > > level. > > Is it just me or is this undesired behaviour? I noticed this back when I > was playing around with error_handlers. > > I think this should be treated as a bug and be changed for two reasons: > 1) It seems illogical that an error_handler is called for an error level > which is disabled in php.ini > 2) It's a performance issue since the custom error handler is called for > e.g. every access to an undefined array index even though I disabled > that warning. > > Opinions? > - Chris > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php