Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83282 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43517 invoked from network); 20 Feb 2015 09:39:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2015 09:39:43 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:20167] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 47/89-25547-DD007E45 for ; Fri, 20 Feb 2015 04:39:41 -0500 Message-ID: <47.89.25547.DD007E45@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> In-Reply-To: Date: Fri, 20 Feb 2015 09:39:33 -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") "Dmitry Stogov" wrote in message news:CA+9eiLu634OpuXVT8NnwZwitqc=S4g8UbbMj+coB4nmQcPXRQQ@mail.gmail.com... > >On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston >wrote: > >> "Rowan Collins" wrote in message news:54E4FAC2.7060200@gmail.com... >> >> >>> Tony Marston wrote on 18/02/2015 10:52: >>> >>>> "Rowan Collins" wrote in message news:54E32CAA.5030600@gmail.com... >>>> >>>>> >>>>> Tony Marston wrote on 17/02/2015 09:59: >>>>> >>>>>> "Rowan Collins" wrote in message news:54E1C993.1070609@gmail.com... >>>>>> >>>>>>> >>>>>>> Tony Marston wrote on 16/02/2015 10:09: >>>>>>> >>>>>>>> This RFC only mentions errors with object methods, so what impact >>>>>>>> would it have with procedural functions. For example, if >>>>>>>> fopen('nonexistantfile.txt') fails the return value is FALSE and an >>>>>>>> E_WARNING is generated, but it is difficult to trap the error >>>>>>>> message (it >>>>>>>> could be a permissions error, for example). Is there any plan to >>>>>>>> convert >>>>>>>> procedural functions to throw exceptions? >>>>>>>> >>>>>>> >>>>>>> As Nikita already said: >>>>>>> >>>>>>> This RFC is strictly about fatal and recoverable fatal errors. >>>>>>>> Changing any >>>>>>>> other error types to exceptions would be a significant >>>>>>>> backwards-compatibility break. That is why I suggested that those functions could be made to switch between throwing an exception or not based on them being included within a try ... catch block (or not) >>>>>>> So, no, since that's currently an E_WARNING, there is no current >>>>>>> plan >>>>>>> to change that case to an exception. If we were writing fopen() from >>>>>>> scratch now, it might be worth considering, but the BC implications >>>>>>> of >>>>>>> changing something from non-fatal to fatal are rather drastic. Currently the only values returned by fopen(), fwrite() and fclose() indicate either success or failure, but not the reason for any failure. >>>>>>> That has absolutely nothing to do with OO vs procedural code, >>>>>>> though. 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 Marston >>>>>>> A procedural function could well have an error condition which >>>>>>> should be >>>>>>> fatal if unhandled, but can usefully be caught somewhere up the >>>>>>> stack, >>>>>>> which is basically what an exception is for. Any procedural function >>>>>>> which >>>>>>> currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to >>>>>>> be >>>>>>> converted under the current RFC. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>> >>>>>> The reason that I mentioned this problem with fopen() - the >>>>>> difficulty >>>>>> with capturing the error message if it fails - is that it also exists >>>>>> with >>>>>> some other functions as well, so it would be nice to be able to put >>>>>> the >>>>>> function in a try ..... catch block so that any and every message >>>>>> could be >>>>>> made available. It is quite obvious that changing fopen() to use >>>>>> exceptions >>>>>> would be a major BC break for all exiting applications, so my >>>>>> question is >>>>>> this: >>>>>> >>>>>> Would it be possible to tell the function if it were being called in >>>>>> a >>>>>> try ... catch bloc or not? If it were then throw an exception, if not >>>>>> then >>>>>> don't throw an exception. I realise that this might be tricky to >>>>>> implement, >>>>>> but if it could be it would allow the developer to choose whether >>>>>> he/she >>>>>> wanted to use exceptions or not instead of having the choice forced >>>>>> upon >>>>>> him/her. >>>>>> >>>>>> Is this possible? Or am I just dreaming? >>>>> >>>>> The point of exceptions is that they don't have to be caught in the >>>>> current scope. So is the below fopen() call "in a try ... catch block" >>>>> for >>>>> the purposes of that check, or not? If putting try { ... } around an >>>>> entire >>>>> application caused all calls to fopen(), in every library it used, to >>>>> stop >>>>> returning false, you'd have exactly the same BC issue as just changing >>>>> it >>>>> permanently. >>>>> >>>>> function foo() { >>>>> try >>>>> { >>>>> $data = load_data(); >>>>> } >>>>> catch ( ... ) { ... } >>>>> } >>>>> >>>>> function load_data() { >>>>> $fh = fopen(...); >>>>> ... >>>>> } >>>>> >>>>> So no, I'm afraid it's probably not possible. >>>>> >>>> >>>> Could it be restricted to the current scope? In your example the call >>>> to >>>> fopen() exists in the load_data() function and is not in a try ... >>>> catch >>>> block within *that* function, so the fact that the call to load_data() >>>> is >>>> within a try ... catch block should be irrelevant as it is in a >>>> different >>>> scope. >>>> >>> If the exception is only thrown when the try - catch is in the same >>> scope, is there really much advantage to it being an exception? When >>> you're >>> that close to the code, sticking an if ( $fh === false ) { ... } around >>> it >>> really isn't that much different from catch(IOException $e) { >> >> The advantage is that you can obtain the reason for the error. All that >> happens with fopen() at the moment is that it returns FALSE which tells >> you >> that it has failed, but it does not tell you why. This is a classic >> example >> of the semipredicate problem for which exceptions were originally >> designed. > >The main advantage is the ability to catch FATAL errors that previously >leaded to script termination and 500 response. > >Thanks. Dmitry. > >> Having the problem be detectable in a higher scope is kind of the point >>> of exceptions. >> >> So is the ability of catching an exception immediately it is thrown so >> that you can obtain the error message. Having the ability to deal with an >> exception at a higher level is only relevant if you don't deal with it >> immediately, either by design or by accident. >> >> -- >> Tony Marston >>