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,
> >> >>>>
> >> >>>> [EMAIL PROTECTED] /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:[EMAIL PROTECTED]
> >> >
> >> >
> >> > --
> >> > 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to