On Tue, Jul 24, 2012 at 5:16 PM, Rasmus Lerdorf <ras...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
