Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61700 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52443 invoked from network); 24 Jul 2012 17:25:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jul 2012 17:25:30 -0000 Authentication-Results: pb1.pair.com header.from=dragoonis@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=dragoonis@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender) X-PHP-List-Original-Sender: dragoonis@gmail.com X-Host-Fingerprint: 209.85.161.170 mail-gg0-f170.google.com Received: from [209.85.161.170] ([209.85.161.170:49158] helo=mail-gg0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 27/02-42538-98ADE005 for ; Tue, 24 Jul 2012 13:25:30 -0400 Received: by ggnf2 with SMTP id f2so7918123ggn.29 for ; Tue, 24 Jul 2012 10:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U4ZaPlzZKh15VKmxnQPZsh19Nfl9tVRzR3tZTezuY4o=; b=xAqMd+rls3t/MK62CVS6Hpywj3wp0ZGSRgUC1enquTcelnTCbuCa9D1QvtIIMPF3NY 9dIPbESRf3Vka8a8ZKxsF2lsowQiFvEXx4izAUVqhyGZEsiHhowQL1V8Nz7gTS2oNh8K y5pS2hoVilmQPUPFGfyUKDJDTic/fUGhbxtNeZUumL48/X5bFD+96Ex0/JfL9B09S8E6 7DfLUwGDQ8ueIbhRfdMVCs6PP3eI0rjDEO9WmVBKoHyMi4wG+0zzvCB5NF8wt18tg7po zVywO8S+RD23d8Llaf2DOl+wASehWB1kxj0VkmHUYWEtN7iFlTdc8myn+ckoxn+Jl3Es 7KWg== MIME-Version: 1.0 Received: by 10.42.50.17 with SMTP id y17mr221520icf.44.1343150727390; Tue, 24 Jul 2012 10:25:27 -0700 (PDT) Received: by 10.64.44.33 with HTTP; Tue, 24 Jul 2012 10:25:27 -0700 (PDT) In-Reply-To: <500ED960.9020505@lerdorf.com> References: <500EBC47.2080200@lerdorf.com> <500ED960.9020505@lerdorf.com> Date: Tue, 24 Jul 2012 18:25:27 +0100 Message-ID: To: Rasmus Lerdorf Cc: Nikita Popov , Laruence , PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions From: dragoonis@gmail.com (Paul Dragoonis) On Tue, Jul 24, 2012 at 6:20 PM, Rasmus Lerdorf 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 >