Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72653 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 32234 invoked from network); 17 Feb 2014 09:27:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Feb 2014 09:27:55 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:33513] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 83/9C-56374-916D1035 for ; Mon, 17 Feb 2014 04:27:54 -0500 Received: (qmail 22583 invoked by uid 89); 17 Feb 2014 09:27:50 -0000 Received: by simscan 1.3.1 ppid: 22576, pid: 22580, t: 0.0644s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 17 Feb 2014 09:27:50 -0000 Message-ID: <5301D6FD.3070607@lsces.co.uk> Date: Mon, 17 Feb 2014 09:31:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 MIME-Version: 1.0 To: PHP internals References: <5301C3A2.3060506@sugarcrm.com> <5301CB23.2090305@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] my take on PHP 6, part 2 From: lester@lsces.co.uk (Lester Caine) Ferenc Kovacs wrote: > Warnings? Both?), make errors not so damn expensive and fix @ to be much > >more lean-and-mean than it is now. > > Kill it could be an option too. I see the need of @ as a design failure. > > Is ICU an indication of how this should be handled as well. Being able to > switch exceptions off in intl demonstrates that they may not be necessary. > > a library which is built around supporting exceptions can work, but currently we > have a bunch of code (both in the core and in userland), which doesn't support that. > errors can support the execution of the execution, which means allowing to have > return values, or emiting multiple errors from the same call, with exceptions > you can't do that, as the execution will jump to the next catch block (or to the > global exception handler). > I don't think I have seen any proposal so far which would solve these issues, > yet people still talking about like replacing the current error handling > infrastructure with exceptions would be a viable alternative. While the discussion has also been opened up to include C++ which use 'exceptions' in normal process flow, IS it a given that we have to have exceptions at all? To my mind proper error handling should prevent the 'white screen' as the only way of handing things when everything has gone tits up? :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk