Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61721
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender)
Message-ID: <500EEC60.3090606@sugarcrm.com>
Date: Tue, 24 Jul 2012 11:41:36 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, Laruence <laruence@php.net>, 
 PHP Internals <internals@lists.php.net>
References: <CABBJUpe-i3o5DcFH_cMJf7QxHmzkE3afjL_TXFrg-mCmOiFa=w@mail.gmail.com> <CAF+90c8xfpCmcMRiTqHrBQfPcHAotkpXfJKVskwycbdGB9R-UA@mail.gmail.com> <500EBC47.2080200@lerdorf.com> <CAF+90c9weB-xoODqoud83NbvvhxYMbRttPu6-YgxwfaMd4d8HQ@mail.gmail.com>
In-Reply-To: <CAF+90c9weB-xoODqoud83NbvvhxYMbRttPu6-YgxwfaMd4d8HQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Still my point stands. If fatal errors and die are not handled by
> finally the feature does not make sense to me. You simply can't do any
> kind of remotely important cleanup in there (like releasing locks
> etc).

Well, I'm sorry you don't understand it but I think you are too focused
on exactly copying what you are accustomed to, and this is not the goal
for PHP.
I don't know what you mean by "important cleanup" but if you mean you do
some persistent things that absolutely need to be cleaned up by code, I
have very bad news for you. PHP is not the language that can do it. PHP
script can be terminated at any moment - by the webserver, by the OS, by
other means - and that'd be just that, it would cease to exist and no
code will be run. finally can not and will not solve this problem. It is
not meant to solve this problem. It is meant to solve specific use-case
of using temporary resources in a block of code and cleaning them
immediately (as opposed to waiting until request-level cleanup).

Fortunately, in my many years of working with PHP I don't think I ever
saw any case where simple OS functions coupled with more powerful
constructs like transactions were not enough to cleanup anything that
PHP script could do.

> Similarly die; is commonly called in code doing header redirects. I
> think it would be unacceptable to not run cleanup clauses in that
> case.

If you need cleanups on the request level, you already have shutdown
functions. Those, btw, aren't guaranteed to run in every case too -
there can be situations, albeit rare, that shutdown could fail and thus
some cleanup not run (e.g. the process being killed, PHP getting out of
memory, etc.). Also, there could be more frequent situation that your
shutdown code has a bug which causes it to terminate early. Which btw
may be a case with Python code too - unless you wrap every statement in
a separate finally clause you have the same issue.

> Another, separate point against finally is that in PHP (unlike many
> other languages) most (all?) built-in resources clean up after
> themselves. So if you open a file you don't have to worry about
> closing it again. It'll do that all by itself as soon as it goes out

You don't have to, but in some cases you better to if you write more
than two-liner, since otherwise, while the file does not survive the
request, with suitable scope it may linger much longer than you expect.
So in some cases having shorter-scope cleanups can be helpful. Of
course, you can also do pretty much the same with RAII pattern - so it's
not strictly necessary. But may be nice to have.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227