On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston <tonymars...@hotmail.com> wrote:
> "Rowan Collins" wrote in message news:54e4fac2.7060...@gmail.com... > > >> Tony Marston wrote on 18/02/2015 10:52: >> >>> "Rowan Collins" wrote in message news:54e32caa.5030...@gmail.com... >>> >>>> >>>> Tony Marston wrote on 17/02/2015 09:59: >>>> >>>>> "Rowan Collins" wrote in message news:54e1c993.1070...@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. >>>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> That has absolutely nothing to do with OO vs procedural code, though. >>>>>> 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. >>>> >>>> Regards, >>>> >>> >>> 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 > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
