Re: [RFC] Supports 'finally' keyword for PHP exceptions

From: Date: Tue, 24 Jul 2012 13:40:23 +0000
Subject: Re: [RFC] Supports 'finally' keyword for PHP exceptions
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-61680@lists.php.net to get a copy of this message
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: >> 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.

« previous php.internals (#61680) next »