Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21292 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58222 invoked by uid 1010); 20 Dec 2005 23:45:03 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 58206 invoked from network); 20 Dec 2005 23:45:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Dec 2005 23:45:03 -0000 X-Host-Fingerprint: 17.250.248.72 smtpout.mac.com FreeBSD 4.8-5.1 (or MacOS X 10.2-10.3) Received: from ([17.250.248.72:52825] helo=smtpout.mac.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 56/32-14561-E7798A34 for ; Tue, 20 Dec 2005 18:45:03 -0500 Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id jBKNixZ1023421; Tue, 20 Dec 2005 15:44:59 -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 jBKNiv9r019131; Tue, 20 Dec 2005 15:44:58 -0800 (PST) In-Reply-To: <20051220171533.M69638@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> <6E2D0033-4F34-42D2-9C2B-EF59C62B83B6@mac.com> <20051220171533.M69638@reverseorder.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: Cc: Marcus Boerger , PHP Content-Transfer-Encoding: 7bit Date: Tue, 20 Dec 2005 18:44:55 -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) > 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. Your question is kindof wrong... you can always throw exceptions in destructors. The problem is CATCHING them. I think probably in languages with GC's that throwing [uncaught] exceptions in destructors is probably a bad idea, unless you DESIRE termination as a result, as you don't know who's calling your destructor. I am not positive that this is a bad idea, but I think so... exceptions are meant to be caught. Uncaught exceptions are typically considered errors, and PHP considers them fatal. This is precisely what's happening to you. The destructor is called from the script termination cleanup code, outside of your program scope, and thus there's no try/catch to catch your exception. I suppose if you really want to do this just for logging, you could use: http://us2.php.net/manual/en/function.set-exception-handler.php But to me this seems like a bad idea. If you have some complicated tear-down machinery that you want to do try/catch with, try a method like "cleanup()" in your class and call it surrounded by try/catch to do your cleanup when you're done with the resource. Alan