Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61697
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <500EBC47.2080200@lerdorf.com>
References: <CABBJUpe-i3o5DcFH_cMJf7QxHmzkE3afjL_TXFrg-mCmOiFa=w@mail.gmail.com>
	<CAF+90c8xfpCmcMRiTqHrBQfPcHAotkpXfJKVskwycbdGB9R-UA@mail.gmail.com>
	<500EBC47.2080200@lerdorf.com>
Date: Tue, 24 Jul 2012 19:01:13 +0200
Message-ID: <CAF+90c9weB-xoODqoud83NbvvhxYMbRttPu6-YgxwfaMd4d8HQ@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Laruence <laruence@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
From: nikita.ppv@gmail.com (Nikita Popov)

On Tue, Jul 24, 2012 at 5:16 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>> 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).
>
> No it doesn't, at least not in Java. A fatal Java error or an explicit
> call to System.exit() will cause the finally clause to not be executed.
> It is a simple exception-level construct and doesn't in any way promise
> to be called in a fatal error situation. And regardless of what Java
> does, we are free to define it and provide whatever promises we want
> here, but keeping it in line with Java's implementation makes sense to me.

I was writing this out of a Python perspective, which gives strong
guarantees for finally. Java indeed reserves the right to not run
finally if System.exit is called.

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).

Please don't forget that in PHP a lot of stuff throws a fatal error.
Some simple oversight like calling $foo->bar()->baz() while
$foo->bar() can also return false or null can lead to a fatal error
that's easily missed during testing.

Similarly die; is commonly called in code doing header redirects. I
think it would be unacceptable to not run cleanup clauses in that
case.

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
of scope. The same applies to database handles, etc. As PHP uses
refcount based garbage collection the resource is actually cleaned up
right away, not just at the next GC run (which could be problematic if
you open up many files in a row).

Nikita