On 13.05.2011 15:44, Don wrote:

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

  OK. Then - when finalizer is called and throws something, program must be terminated - as there is no catch.

/Alexander

On 13.05.2011 15:47, Don wrote:

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

  Why? If object holds some external resource, which needs to be released (like file handle) - that makes perfect use case, IMHO.

  It *could* happen that explicit release didn't happen, that's why finalizer should do this.

/Alexander

On 2011-05-13 09:44:33 -0400, Don <nospam@nospam.com> said:

> If the GC calls it, it's a finalizer, not a destructor.
> 
> Structs have destructors, and it's perfectly OK to throw inside them.

Really? What if you allocated the struct on the heap, as a member of a class, or in an array? The struct will be on the heap and its destructor will become the finalizer.

What you say about structs makes sense only as long as structs are confined to the stack. In reality, structs can also be on the heap.

Discussion for bug 4621's has a long discussion about this issue.
<http://d.puremagic.com/issues/show_bug.cgi?id=4621>

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

On 2011-05-13 08:06, Michel Fortin wrote:
> On 2011-05-13 09:44:33 -0400, Don <nospam@nospam.com> said:
> > If the GC calls it, it's a finalizer, not a destructor.
> > 
> > Structs have destructors, and it's perfectly OK to throw inside them.
> 
> Really? What if you allocated the struct on the heap, as a member of a class, or in an array? The struct will be on the heap and its destructor will become the finalizer.
> 
> What you say about structs makes sense only as long as structs are confined to the stack. In reality, structs can also be on the heap.
> 
> Discussion for bug 4621's has a long discussion about this issue. <http://d.puremagic.com/issues/show_bug.cgi?id=4621>

Well, assuming that a struct's destructor is called when it's garbage collected from the heap (which as I recall, doesn't ever happen at this point), couldn't the GC just catch any exceptions that it throws and then throw the appropriate Error? Then the destructor could throw just fine while it's on the stack, but you'd get the FinalizerError (or whatever it's called) when it happens on the heap.

- Jonathan M Davis

They effectively are. When a finalized throws its wrapped in a FinalizerError or something of the sort. This is old code from when Walter said that it should be illegal for a finalizer to throw (rule should be revised with new chaining rules, but it works for now).

Sent from my iPhone

On May 13, 2011, at 1:25 AM, 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.

On 05/13/2011 04:44 PM, Don wrote:
> 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.

Destructor/finalizer confusion is one of D's weakest spots. GC and "delete" (now - "clear") should have never been designed to call the same function. Now that there are talks about making GC call destructors on structs, structs are at the threat of becoming as broken as classes are.

On 2011-05-13 13:16:03 -0400, Max Samukha <maxter@spambox.com> said:

> On 05/13/2011 04:44 PM, Don wrote:
>> If the GC calls it, it's a finalizer, not a destructor.
>> 
>> Structs have destructors, and it's perfectly OK to throw inside them.
> 
> Destructor/finalizer confusion is one of D's weakest spots. GC and "delete" (now - "clear") should have never been designed to call the same function. Now that there are talks about making GC call destructors on structs, structs are at the threat of becoming as broken as classes are.

They're already broken in subtle and racy ways because of this. A few examples:
<http://d.puremagic.com/issues/show_bug.cgi?id=4624>

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

On Fri, 13 May 2011 10:01:56 -0400, dsimcha <dsimcha@yahoo.com> wrote:
> == 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.

I use the finalizers of proxy classes to manage GPU memory.

On Fri, 13 May 2011 17:01:56 +0300, dsimcha <dsimcha@yahoo.com> wrote:

> == 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.

In my case, it was mainly because D1 has no struct destructors.

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