On 24/07/12 14:40, Levi Morrison wrote:
On Tue, Jul 24, 2012 at 7:35 AM, Nikita Popov <nikita....@gmail.com> wrote:
On Tue, Jul 24, 2012 at 1:20 PM, Laruence <larue...@php.net> wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
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.php
I definitely agree with Mr. Nikita Popov. Unless we have a
guarantee of `finally` running 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
