Am 13.05.2011 10:33, schrieb Vladimir Panteleev:
> On Fri, 13 May 2011 11:22:11 +0300, Daniel Gibson <metalcaedes@gmail.com> wrote:
> 
>> It may be sane to just define that destructors are nothrow and if they throw anyway to terminate the program.
>>
>> What is the current behaviour anyway? ;)
> 
> D2 throws a FinalizeError (which is an Error, so "not recoverable").

So the program is terminated? In that case you don't really have to worry about the state of the GC, right?

> D1 just allows the exception to propagate through the GC to whatever
> caused a GC to run.
> Both leave the GC in an indeterminate state, as far as I can tell.
> 

On 13.05.2011 10:25, Don wrote:

> Are you talking about *finalizers* or *destructors* ?

  Destructors as defined in D spec. There are no finalizers (yet), AFAIK.

> Throwing from inside a destructor should definitely work (unlike C++).

  How? Destructor is called by the GC when object is deleted. When and where (which thread) this happens is unknown, it is done outside of regular flow of execution - so who and where can catch this exception? So, like any other uncatched exception,
it will terminate the program.

> But finalizers should probably be nothrow.

  Once they are implemented :) In any case, as long as there is no try/catch around GC collection, I see little use for exceptions apart from terminating the program.

  If, however, we are talking about using try/catch blocks inside of destructors - then of course, this should be possible.

/Alexander

On 13.05.2011 10:12, Vladimir Panteleev wrote:

> Yes, but what if it's handled (there's a try/catch block around the allocation or fullCollect call that invoked the GC)?

  Oh, that case... Sure, if GC is buggy and throw causes GC allocation in turn... then we have a problem, of course, but of course, this should work - normally.

/Alexander

On Fri, 13 May 2011 11:41:04 +0300, Daniel Gibson <metalcaedes@gmail.com> wrote:

> Am 13.05.2011 10:33, schrieb Vladimir Panteleev:
>> On Fri, 13 May 2011 11:22:11 +0300, Daniel Gibson
>> <metalcaedes@gmail.com> wrote:
>>
>>> It may be sane to just define that destructors are nothrow and if they
>>> throw anyway to terminate the program.
>>>
>>> What is the current behaviour anyway? ;)
>>
>> D2 throws a FinalizeError (which is an Error, so "not recoverable").
>
> So the program is terminated? In that case you don't really have to
> worry about the state of the GC, right?

I guess, but this requires that the user does not use catch(Object) or catch(Throwable).
I don't know if this is acceptable for SafeD, for example.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Fri, 13 May 2011 12:28:01 +0300, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> I guess, but this requires that the user does not use catch(Object) or catch(Throwable).

Also just catch { ... }, of course (I don't understand why that's in the language at all).

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On 2011-05-13 04:34:06 -0400, "Vladimir Panteleev" <vladimir@thecybershadow.net> said:

> Come to think of it, SafeD shouldn't allow accessing anything on the heap  in finalizers as well...

Back to bug 4621.
<http://d.puremagic.com/issues/show_bug.cgi?id=4621>

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Fri, 13 May 2011 11:41:04 +0300, Daniel Gibson <metalcaedes@gmail.com> wrote:

> So the program is terminated? In that case you don't really have to
> worry about the state of the GC, right?

After looking again at it, my patch actually does "the right thing" and locks out the GC after a finalizer exception (any attempt to access the GC from that point will instantly throw), so I've sent the pull requests. Thanks for the feedback.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

Alexander wrote:
> On 13.05.2011 10:25, Don wrote:
> 
>> Are you talking about *finalizers* or *destructors* ?
> 
>   Destructors as defined in D spec. There are no finalizers (yet), AFAIK.

The things in classes which the spec calls "destructors" are finalizers, not destructors.

> 
>> Throwing from inside a destructor should definitely work (unlike C++).
> 
>   How? Destructor is called by the GC when object is deleted. When and where (which thread) this happens is unknown, it is done outside of regular flow of execution - so who and where can catch this exception? So, like any other uncatched exception,
> it will terminate the program.

If the GC calls it, it's a finalizer, not a destructor.

Structs have destructors, and it's perfectly OK to throw inside them.

Vladimir Panteleev wrote:
> On Fri, 13 May 2011 11:25:01 +0300, Don <nospam@nospam.com> wrote:
> 
>> Alexander wrote:
>>> On 13.05.2011 06:53, Vladimir Panteleev wrote:
>>>
>>>> Thus, my question is: what's the expected behavior of D programs when a destructor throws?
>>>    I would say, the only expected (and correct, IMHO) behavior should be termination of the program because of unhandled exception.
>>>  /Alexander
>>
>> Are you talking about *finalizers* or *destructors* ?
>>
>> Throwing from inside a destructor should definitely work (unlike C++).
>> But finalizers should probably be nothrow.
> 
> How would you distinguish the two in the language? Class destructors = finalizers?

Yes.
struct destructor = destructor

> Come to think of it, SafeD shouldn't allow accessing anything on the heap in finalizers as well...

Yeah. It's pretty hard to come up with a use case for a finalizer.

== Quote from Don (nospam@nospam.com)'s article
> Yeah. It's pretty hard to come up with a use case for a finalizer.

This is why I'm so interested in improving D's GC yet have shown so little interest in this bug.  I can't even figure out what finalizers are for and basically never use them.  Even in the cases where I have used them before to get around false pointer issues, I now realize that such uses were actually latent race conditions.