Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:24344 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 24346 invoked by uid 1010); 11 Jul 2006 19:12:07 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 24331 invoked from network); 11 Jul 2006 19:12:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jul 2006 19:12:06 -0000 X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6 Received: from ([81.169.182.136:49247] helo=strato.aixcept.de) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id CC/11-15035-508F3B44 for ; Tue, 11 Jul 2006 15:12:05 -0400 Received: from baumbart.mbo (dslb-084-063-030-119.pools.arcor-ip.net [84.63.30.119]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by strato.aixcept.de (Postfix) with ESMTP id 83E8735C24C; Tue, 11 Jul 2006 20:38:55 +0200 (CEST) Date: Tue, 11 Jul 2006 20:39:09 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <1074809844.20060711203909@marcus-boerger.de> To: Michael Wallner Cc: internals@lists.php.net In-Reply-To: <44.90.38316.ED1C3B44@pb1.pair.com> References: <97.00.12962.7DE73B44@pb1.pair.com> <44B38343.9030403@zend.com> <44.90.38316.ED1C3B44@pb1.pair.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: More valuable error message handling From: helly@php.net (Marcus Boerger) Hello Michael, yep, here too. track_errors is an optimizations when you don't want to debug but simply use your app. best regards marcus Tuesday, July 11, 2006, 5:21:09 PM, you wrote: > Antony Dovgal wrote: >> On 11.07.2006 14:38, Lukas Smith wrote: >>> Michael Wallner wrote: >>> >>>> - error_get_last() >>>> Get the last error message. >>> >>> my wish would be that this one should work even if track_errors is not >>> enabled. >> >> Yes, these functions should not depend on any INI directives. > I'm with Ilia and think that there should be the possibility to > disable this and track_errors seems like the perfect and already > existing fit. > Regards, > -- > Michael Best regards, Marcus