Re: [RFC] Supports 'finally' keyword for PHP exceptions
| From: | Andrew Faulds | Date: | Tue, 24 Jul 2012 13:43:59 +0000 |
| Subject: | Re: [RFC] Supports 'finally' keyword for PHP exceptions | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-61681@lists.php.net to get a copy of this message | ||
On 24/07/12 14:40, Levi Morrison wrote:
On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:On Tue, Jul 24, 2012 at 1:20 PM, Laruence <laruence@php.net> wrote:I definitely agree with Mr. Nikita Popov. Unless we have a guarantee ofHi:The finally clause comes with a very strong promise that the code in the clause will run in absolutely any case (short of sigkill, maybe). In particular this means that... ... if a die() is execute somewhere in the try clause (or a called function) the finally clause must still be run. ... if a parse error or other fatal error occurs in the try clause (or called function) the finally clause must still be run. ... if the user interrupts the process the finally clause must still be run. Basically this requires that all of the actions that are currently fatal need to be converted to exceptions. E.g. Python has special SystemExit and KeyboardInterrupt exceptions, as well as SyntaxError and so on. I obviously think that PHP should adopt this model too (as it gives the programmer more control), but until all fatal actions are turned into exceptions, I'm strongly against introducing "finally". The main point of the clause is to have a guarantee, and that is simply currently not present. You actually get a better guarantee if you just use destructors. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phpAs the previous threads disscussed, I make a implemention.here is the RFC: https://wiki.php.net/rfc/finallyany suggestions?finallyrunning for PHP fatal errors, then this is not particularly useful. I also agree with Mr. Popov here. PHP's fatal errors are, well, fatal, meaning we can do absolutely nothing about them. I guess that's something to change for PHP6: making them into serious exceptions, but ones that can be caught (maybe a different class, like Java's RuntimeErrors and Exceptions, IIRC). Obviously things like running out of memory can't be dealt with, though.