Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21294 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67132 invoked by uid 1010); 21 Dec 2005 00:14:58 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 67117 invoked from network); 21 Dec 2005 00:14:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Dec 2005 00:14:58 -0000 X-Host-Fingerprint: 84.92.162.233 scuzzy.plus.com Linux 2.5 (sometimes 2.4) (4) Received: from ([84.92.162.233:38545] helo=reverseorder.net) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 0B/23-14561-08E98A34 for ; Tue, 20 Dec 2005 19:14:57 -0500 Received: from reverseorder ([127.0.0.1] helo=reverseorder.net) by reverseorder.net with esmtp (Exim 3.36 #1 (Debian)) id 1EorcV-0007BI-00; Wed, 21 Dec 2005 00:14:15 +0000 To: Marcus Boerger Cc: Alan Pinstein ,PHP Reply-To: scuzzy@reverseorder.net Date: Wed, 21 Dec 2005 00:14:15 +0000 Message-ID: <20051220235916.M7868@reverseorder.net> In-Reply-To: <1583077781.20051220212730@marcus-boerger.de> References: <20051216141608.M76819@reverseorder.net> <124842700.20051216203820@marcus-boerger.de> <20051219100552.M48206@reverseorder.net> <1649362906.20051219201607@marcus-boerger.de> <20051220134857.M91845@reverseorder.net> <6E2D0033-4F34-42D2-9C2B-EF59C62B83B6@mac.com> <20051220171533.M69638@reverseorder.net> <1583077781.20051220212730@marcus-boerger.de> X-Mailer: Open WebMail 2.41 20040926 X-OriginatingIP: 192.168.0.2 (scuzzy) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: Re: [PHP-DEV] exceptions in the destructor From: scuzzy@reverseorder.net ("Daine Mamacos") Marcus, I'm not trying to argue with you, I'm just after some help. You are confusing me somewhat. The php manual clearly states: "Note: Attempting to throw an exception from a destructor causes a fatal error." I'm somewhat convinced that you cannot throw an exception from a destructor, well you can, but it gets you nowhere. What does forcing the call of a destructor have to do with this conversation? If you can think of a way of working around this, that would be greatly appreciated. Anyway, Thanks Daine Mamacos On Tue, 20 Dec 2005 21:27:30 +0100, Marcus Boerger wrote > Hello Daine, > > a) i didn't contradict myself - you obviously didn't really follow > what i wrote > > b) you can force calling the destructor by using unset() or = null; > but only if reference count is 1. > c) exceptions are 'thrown' not called, maybe you didn't use throw new > exception here or you were just writing a bit weired? > d) as said already several times (not only to you) exceptions *can* > be thrown in destructors > > e) this doesn't belong in internals@ > > regards > marcus > > Tuesday, December 20, 2005, 6:22:31 PM, you wrote: > > > I agree completely... > > I think the GC should be better documented. > > I also would like someone to tell me why exceptions cannot be called in the > > destructor? Since they can't, this means the reliability of a destructor is > > uncontrolled and nothing can be done to see if this completes successfully. > > > This in some way or another, renders them completely useless if you require > > them to complete an operation and at least have the peace of mind that you > > will be able to deal with errors rather than the application throwing a fatal > > error. > > > On Tue, 20 Dec 2005 11:38:34 -0500, Alan Pinstein wrote > >> > 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 > >> > > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > > > -- > > random signature > > Best regards, > Marcus -- random signature