
PHP finally gets finally - TazeTSchnitzel
https://wiki.php.net/rfc/finally?&#changelog
======
randomdrake
This is an exciting step forward for being able to prevent repetitious code
and handle exceptions more elegantly. More excitement will be had when we
actually see this implemented in an upcoming version.

In case you are wondering why this link goes to the bottom of the page, the
important bit is:

 _2012/08/13 Xinchen Hui: Close voting, RFC win the voting_

The RFC is a bit dry and does explain some use cases, however, GoogleGuy (who
is a really nice and helpful guy in the ##php channel) provided a wonderful
explanation[1] that goes into more detail.

Accepting the RFC is just the first step, let's hope we can see this in the
next version.

[1] - <http://sheriframadan.com/2012/08/finally-keyword-in-php/>

~~~
TazeTSchnitzel
Oh, it will be, laruence is merging into master. Although whether it is 5.5 or
6.0 remains to be seen.

Also, looks like generators may come to vote soon since NikiC has asked on
mailing list about it. <http://wiki.php.net/rfc/generators>

------
kijin
This should have been implemented back in PHP 5.0, when exceptions were first
introduced. A try-catch block without finally is only half complete!

But it's great to see half-complete features becoming fully complete, even if
a few years late.

~~~
TazeTSchnitzel
The main argument against it (that keeps coming up on ML) is destructors and
resources cleaning up after themselves. Pretty weak argument though.

~~~
ceol
Yes, considering OOP and exceptions are not dependent on each other.

------
Joeri
I always loved the first response to the request to implement finally. It was
so delightfully arrogant.

<https://bugs.php.net/bug.php?id=32100>

By the way, if you scroll down in that page there are two workaround solutions
to get the finally behavior on any php5 version.

------
spdy
Does it now catch system exceptions as well? Something that drove me away from
php that i was not able to catch all errors inside an exception block.

~~~
wwweston
I think this has been possible more or less since PHP introduced exceptions by
using `set_error_handler`:

<http://php.net/manual/en/function.set-error-handler.php>

along with a function that throws exceptions, e.g.:

function exception_on_error($errnum,$errmsg) { throw new
ErrorException($errmsg,$errnum); }

You can't catch _all_ errors (sensibly including compile errors and unhandled
exception errors), but it can get you pretty far.

Not that there aren't other reasons not to use PHP, but this one is
manageable.

------
irunbackwards
Is it possible to see the reasoning behind the 'no' votes?

~~~
sharken
Short of asking the involved parties, the best you can do is to follow some of
the PHP discussions on this topic, such as this one [http://www.mail-
archive.com/internals@lists.php.net/msg59731...](http://www.mail-
archive.com/internals@lists.php.net/msg59731.html)

The first use-case for finally involved locking database tables, and then
unlocking them in the finally clause. It would be pretty bad, if you could not
guarantee the unlock would happen. So one would hope that has been properly
taken care of :-)

------
ExpiredLink
PHP has no destructors?

~~~
chc
Destructors aren't a good way to free resources in a garbage collected
language.

~~~
tomjen3
I have yet to see a language that actually cleans up after itself. Many will
attempt to free memory, but what about files, db connections, windows,
sockets?

~~~
reginaldo
Have you heard about Racket's _custodians_? [1] [http://docs.racket-
lang.org/reference/eval-model.html#(part....](http://docs.racket-
lang.org/reference/eval-model.html#\(part._custodian-model\))

------
PaulHoule
sugoi!

------
pjbeardsley
Finally.

