Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:24441 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81061 invoked by uid 1010); 17 Jul 2006 21:56:42 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 81046 invoked from network); 17 Jul 2006 21:56:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jul 2006 21:56:42 -0000 X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:45952] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id D8/E9-11992-0970CB44 for ; Mon, 17 Jul 2006 17:56:39 -0400 Received: (qmail 24777 invoked from network); 17 Jul 2006 21:55:32 -0000 Received: from localhost (HELO zeev-notebook.zend.com) (127.0.0.1) by localhost with SMTP; 17 Jul 2006 21:55:32 -0000 Message-ID: <7.0.1.0.2.20060718005559.06087fa0@zend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 18 Jul 2006 00:56:23 +0300 To: Ilia Alshanetsky Cc: internals@lists.php.net In-Reply-To: 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"; format=flowed Subject: Re: [PHP-DEV] Re: More valuable error message handling From: zeev@zend.com (Zeev Suraski) Agreed - it looks good, but should return an array instead of an object. Zeev At 00:33 18/07/2006, Ilia Alshanetsky wrote: >Looks good to me, although I'd prefer you returned an associated >array rather then an object. > > >On 17-Jul-06, at 6:03 AM, Michael Wallner 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 >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: >>http://www.php.net/unsub.php >> > >Ilia Alshanetsky > > >