Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83787 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52620 invoked from network); 25 Feb 2015 14:06:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2015 14:06:49 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:44661] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 76/42-62407-7F6DDE45 for ; Wed, 25 Feb 2015 09:06:47 -0500 Received: (qmail 23684 invoked by uid 89); 25 Feb 2015 14:06:44 -0000 Received: by simscan 1.3.1 ppid: 23674, pid: 23680, t: 0.0771s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 25 Feb 2015 14:06:43 -0000 Message-ID: <54EDD6F3.8070309@lsces.co.uk> Date: Wed, 25 Feb 2015 14:06:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: <54E12349.7070806@gmail.com> <16.9B.05176.AE1C1E45@pb1.pair.com> <54E1C993.1070609@gmail.com> <37.20.01961.31113E45@pb1.pair.com> <54E32CAA.5030600@gmail.com> <54E4FAC2.7060200@gmail.com> <47.89.25547.DD007E45@pb1.pair.com> <54EDCBD6.70302@gmail.com> In-Reply-To: <54EDCBD6.70302@gmail.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine From: lester@lsces.co.uk (Lester Caine) On 25/02/15 13:19, Rowan Collins wrote: >>> Tony, first of all - this still breaks BC, because exception is being >>> thrown in a place where it used not to be... >> >> I disagree. The following function calls would not throw exceptions >> fopen(...); >> fwrite(...); >> fclose(...); >> >> while the following code would: >> try { >> fopen(...); >> fwrite(...); >> fclose(...); >> } catch (....) { >> .... >> } > > But what about this code, which could well already exist: > > try { > $fh = fopen(...); > $this->processLotsOfDataAndMaybeThrowAnException($fh); > fclose($fh); > } catch (....) { > .... > } > > If fopen() starts throwing exceptions here, that's as much a BC break as > it throwing them everywhere. If it doesn't, the rules for when it should > throw become even more complicated, and useful in even fewer cases. That is certainly the sort of scenario that I am concerned about. try/catch blocks have been added through a lot of libraries and if the returns now change then currently working code starts to fail. Fixing the extra exceptions looks more interesting, so referring to the first try block above, having to catch different exceptions from each function is the problem here. But I still prefer dealing with the error as part of the function call so I can at least respond in the same context. -- 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