Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21285 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84225 invoked by uid 1010); 20 Dec 2005 16:38:42 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 84210 invoked from network); 20 Dec 2005 16:38:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Dec 2005 16:38:42 -0000 X-Host-Fingerprint: 17.250.248.45 smtpout.mac.com FreeBSD 4.8-5.1 (or MacOS X 10.2-10.3) Received: from ([17.250.248.45:51664] helo=smtpout.mac.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 78/CB-14561-19338A34 for ; Tue, 20 Dec 2005 11:38:42 -0500 Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout11/MantshX 4.0) with ESMTP id jBKGcbQI018904; Tue, 20 Dec 2005 08:38:37 -0800 (PST) Received: from [10.0.1.102] (c-24-98-128-251.hsd1.ga.comcast.net [24.98.128.251]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id jBKGcZ0g026423; Tue, 20 Dec 2005 08:38:36 -0800 (PST) In-Reply-To: <20051220134857.M91845@reverseorder.net> References: <20051216141608.M76819@reverseorder.net> <124842700.20051216203820@marcus-boerger.de> <20051219100552.M48206@reverseorder.net> <1649362906.20051219201607@marcus-boerger.de> <20051220134857.M91845@reverseorder.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: <6E2D0033-4F34-42D2-9C2B-EF59C62B83B6@mac.com> Cc: Marcus Boerger , PHP Content-Transfer-Encoding: 7bit Date: Tue, 20 Dec 2005 11:38:34 -0500 To: scuzzy@reverseorder.net X-Mailer: Apple Mail (2.746.2) Subject: Re: [PHP-DEV] exceptions in the destructor From: apinstein@mac.com (Alan Pinstein) > Your last post also indicates, that because the destructors are > only called > after script termination, the scope of an object is global, always. > Is this true? This isn't true, at least empirically. Destructors are called when the GC frees the object. For many objects, this is at script termination. But if you null out the ref to an object, it will occur immediately. $a = new A(); $a = null; // destructor called just after this line I am not certain that this should be considered *predictable* behavior, as the behavior of the GC is not well/publicly documented to my knowledge, and thus this is a reasonable question for the internals list. Personally I would like to see more documentation of how GC works so that we as developers can depend on it a little better for OO cleanup activities. I have another thread going that still remains unanswered about how to prevent circular references to objects that deadlock the GC. Alan > Also, I've called fwrite in a destructor before, so clearly not all > IO is > terminated before the destructor is called. > When you refer to output facility, what are you talking about? > > Many thanks > Daine Mamacos. > > > On Mon, 19 Dec 2005 20:16:07 +0100, Marcus Boerger wrote >> Hello Daine, >> >> you still don't get it. Your problem is the way php works. You >> cannot put any output functionality in destructors because they are >> called *after* your scipt is being terminted (to be precise after >> the output facility has been shutdown on script termination). >> >> This is btw a question the general php list. >> >> marcus >> >> Monday, December 19, 2005, 11:07:53 AM, you wrote: >> >>> While you're example works, mine doesn't, it has to do with the >>> class >>> assignment. If you actually bother to do anything with the class, it > doesn't work. >> >>> $ php -r 'class blah { function __destruct() { throw new Exception >>> ("exception >>> thrown"); } } $blah = new blah();' >> >>> give that a try and see what happens >>> (; >>> also http://bugs.php.net/bug.php?id=33598 clearly states that >>> they cannoy be >>> thrown in the destructor. >>> Errrr... *shrug* >> >>> On Fri, 16 Dec 2005 20:38:20 +0100, Marcus Boerger wrote >>>> Hello Daine, >>>> >>>> marcus@zaphod /usr/src/PHP_5_1 $ php -r 'class A{function >>>> __destruct(){throw new Exception("A");}} new A;' make: >>>> `sapi/cli/php' is up to date. >>>> >>>> Fatal error: Uncaught exception 'Exception' with message 'A' in >>>> Command line code:1 Stack trace: >>>> #0 Command line code(1): A::__destruct() >>>> #1 {main} >>>> thrown in Command line code on line 1 >>>> >>>> As the code above clearly show, exceptions can be thrown. >>>> >>>> marcus >>>> >>>> Friday, December 16, 2005, 3:17:54 PM, you wrote: >>>> >>>>> Is there any reason why one is not allowed to throw an >>>>> exception in the >>>>> destructor of a class? >>>>> I mean, it makes sense, considering this is not always the >>>>> final step > of code, >>>>> and it is usually used for finalising things, and it would be a >>>>> good > idea to >>>>> know if anything goes wrong at that stage. >>>>> Otherwise is there any compromise one can use to "emulate" this >>>>> feature? >>>> >>>>> Daine Mamacos. >>>> >>>>> -- >>>>> random signature >>>> >>>> Best regards, >>>> Marcus >>>> >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: http://www.php.net/unsub.php >> >>> -- >>> random signature >> >> -- >> Best regards, >> Marcus mailto:mail@marcus-boerger.de > > > -- > random signature > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >