Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83468 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85115 invoked from network); 22 Feb 2015 11:07:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Feb 2015 11:07:28 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:25682] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 41/C1-09723-C68B9E45 for ; Sun, 22 Feb 2015 06:07:25 -0500 Message-ID: <41.C1.09723.C68B9E45@pb1.pair.com> 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> In-Reply-To: Date: Sun, 22 Feb 2015 11:07:15 -0000 Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Posted-By: 80.177.120.119 Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine From: TonyMarston@hotmail.com ("Tony Marston") "Pierre Joye" wrote in message news:CAEZPtU7vt=PpK4p3VFZFLAEPzi_wfr2Hr_av+dtzVD6D2dZCSw@mail.gmail.com... > >On Feb 21, 2015 2:08 AM, "Tony Marston" wrote: >> >> ""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc... >> >>> >>> On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston >>> >wrote: >>>> >>>> >>>> I disagree. Exceptions were originally invented to solve the >semipredicate problem which only exists with procedural functions, not >object methods. Many OO purists would like exceptions to be thrown >everywhere, but this would present a huge BC break. If it were possible get >these functions to throw an exception ONLY when they are included in a try >... catch block then this would not break BC at all. >>>> >>> >>> 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 (....) { >> >> .... >> } >> >>> When some function's result heavily depends on the context it makes said >function much harder to reason about. And creates mental overhead for those >who'll have to read the code with this function. >>> >>> And again, if you need exceptions for fopen please consider using >SplFileObject. >> >> >> For file usage, yes. But are there any other procedural functions without >an Spl* alternative which would benefit from this technique? > >Expected failures should not raise exception. For example, IOs are expected >to fail (be network, filesystem etc), I would really not be in favor of >adding exceptions for similar cases. This is a normal control flow. "Pierre Joye" wrote in message news:CAEZPtU7vt=PpK4p3VFZFLAEPzi_wfr2Hr_av+dtzVD6D2dZCSw@mail.gmail.com... > >On Feb 21, 2015 2:08 AM, "Tony Marston" wrote: >> >> ""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc... >> >>> >>> On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston >>> >wrote: >>>> >>>> >>>> I disagree. Exceptions were originally invented to solve the >semipredicate problem which only exists with procedural functions, not >object methods. Many OO purists would like exceptions to be thrown >everywhere, but this would present a huge BC break. If it were possible get >these functions to throw an exception ONLY when they are included in a try >... catch block then this would not break BC at all. >>>> >>> >>> 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 (....) { >> >> .... >> } >> >>> When some function's result heavily depends on the context it makes said >function much harder to reason about. And creates mental overhead for those >who'll have to read the code with this function. >>> >>> And again, if you need exceptions for fopen please consider using >SplFileObject. >> >> >> For file usage, yes. But are there any other procedural functions without >an Spl* alternative which would benefit from this technique? > >Expected failures should not raise exception. For example, IOs are expected >to fail (be network, filesystem etc), I would really not be in favor of >adding exceptions for similar cases. This is a normal control flow. Then why do SplFileInfo::openFile and SplFileObject::__construct throw exceptions if the file cannot be opened? -- Tony Marston