On Tue, Jul 24, 2012 at 6:20 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> On 07/24/2012 10:01 AM, Nikita Popov wrote:
>
>> 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).
>
> Which is the argument for why finally doesn't need to worry about the
> fatal-error case. Most resources are cleaned up on a fatal already,
> including your lock example, so it isn't an issue. finally is
> exception-level for intra-app cleanup, not for request shutdown cleanup.
> We already have shutdown functions for that case.
Exactly what I've been thinking.
If people are already doing die() in their code, they already don't
care about manually freeing up resources and will let php do its
shutdown process as normal.
I think existing concerns about php's resource freeing upon fatal
errors have been accidentally merged with the finally{} proposal,
which shouldn't be looking to change how things work, but provide an
additional block for further control.
I have had to workaround stuff in my PHP apps because of a lack of
finally{} block, and I hope it makes its way into the next iteration.
Thanks,
Paul.
>
> -Rasmus
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
