Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:24438 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 69286 invoked by uid 1010); 17 Jul 2006 21:28:00 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 69270 invoked from network); 17 Jul 2006 21:27:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jul 2006 21:27:59 -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:44432] helo=strato.aixcept.de) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id D0/A8-11992-9D00CB44 for ; Mon, 17 Jul 2006 17:27:55 -0400 Received: from baumbart.mbo (dslb-084-063-021-240.pools.arcor-ip.net [84.63.21.240]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by strato.aixcept.de (Postfix) with ESMTP id 226C135C1F8; Mon, 17 Jul 2006 23:27:51 +0200 (CEST) Date: Mon, 17 Jul 2006 23:28:00 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <702999098.20060717232800@marcus-boerger.de> To: Michael Wallner Cc: internals@lists.php.net, Lukas Smith , Marcus Boerger , , Andi Gutmans , Antony Dovgal In-Reply-To: <44BB607F.1090403@php.net> References: <97.00.12962.7DE73B44@pb1.pair.com> <44B38343.9030403@zend.com> <44.90.38316.ED1C3B44@pb1.pair.com> <1074809844.20060711203909@marcus-boerger.de> <44B41558.1060101@php.net> <44BB607F.1090403@php.net> 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, looks quite good now :-) If it were up to me i'd say commit. best regards marcus Monday, July 17, 2006, 12:03:43 PM, you wrote: > Lukas Smith wrote: >> thats why i said that i would like to atleast be able to get the last >> error without having to mess/check track_errors ini setting. i think >> this is an acceptable compromise to always store the last error, no? >> >> this covers 100% of all use cases i ever had where i would mess with >> the track_errors setting at runtime. > Here's a less impacting patch for an error_get_last() function: > http://dev.iworks.at/PATCHES/error_get_last.diff.txt > Can we agree on that? > -- > Michael Best regards, Marcus