Re: [RFC] Exceptions in the engine

On 27 окт. 2013 г., at 1:40, Nikita Popov <nikita.ppv@gmail.com> wrote: > Reading through the mails in this thread a lot of people seem to have > concerns about backwards compatibility. I can see where this comes from, > "switch to using exceptions" certainly sounds like a seriously big BC break > - but I don't think it actually is. > > Let's start by considering only E_ERROR (and leave recoverable fatals for > later): +1 > First of all we should establish that fatal errors do not occur during > normal program execution. If you take your PHP 5.5 program and run it on > PHP 5.6 (with E_ERROR converted to exceptions) you will see *absolutely no > difference*. If you do, that means your code was previously throwing a > fatal error already, i.e. it didn't actually work in the first place. Let > me say this again, because I think it's important: If your code was working > previously, it will continue working the same way after converting fatals > to exceptions. > > But what happens when the program has a bug and does throw a fatal error? > In this case the program already doesn't work, so what changes isn't > particularly critical, but we should still consider it. There are basically > two things that might happen: > > 1. Most likely everything will work just as you expect, the error will only > be presented differently. Either because the exception is not handled and > the message changes because of that (with stack trace) or an > exception-handler or top-level catch-block handles it rather than the > shutdown function and presents it in some different way. In either case > this shouldn't matter - I certainly do hope that changing the look of an > error is not considered a compatibility break... > 2. A misplaced catch-and-ignore block catches the fatal error and dismisses > it. This is of course unfortunate, but it's really not more than that. It's > an inconvenience, yes, but it does not actually break anything. Some people > have mentioned something about code-paths becoming reachable that were > previous not, but I don't see how that applies. If you used a try/catch > block, then you already expect that the code-path in the catch or the code > after it may be taken. At this point I'd also like to point out that if > code contains a catch-all block, it likely is also supposed to catch-all, > so hiding the error is likely not even wrong. PHP never did Java's mistake > of introducing checked exceptions, so PHP does not have a widespread > pattern of "wrap everything with catch(Exception $e) to silence the > compiler". I think it is a good idea to avoid #2 altogether by introducing BaseException and using separate hierarchy for ex-fatal errors. old code will ignore new exceptions and those will fall thru down to generic exception-handler and shutdown-handler New code will be able to use catch (BaseException $e) but that should be deliberate decision by code-author > So, that much on fatal errors. What about E_RECOVERABLE_ERROR? > > Here there may actually be BC issues. As already mentioned, recoverable > fatals can currently be ignored with a custom error handler and exceptions > make that impossible. So it might be that someone wrote an application that > throws recoverable errors during "normal" program execution. I don't think > that this is particularly realistic and as such I don't think this is > really problematic, but others might see this differently. If that is the > case it might become necessary to keep recoverable fatal errors as is. > > In conclusion, I don't see any non-negligible BC issues for the fatal-error > change and only minor BC issues for the recoverable-fatal change (and even > that can be dropped). As such I don't think pushing this off to PHP 6 is > justified. I'd also like to point out that this RFC is a blocker for some > of my other proposals. In particular, I don't think that I can in good > conscience move the named arguments and argument unpacking RFCs forward > without the ability to use exceptions. I would really hate to move named > args off to PHP 6. I think “safe" set of changes (E_ERROR + separate exceptions-hierarchy) should be implemented in 5.6. Everything else should be planned for 6.x -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc

Attachment: [application/pgp-signature] Message signed with OpenPGP using GPGMail signature.asc