Garbage Collection, Untraceable Errors...

[cy via Digitalmars-d]

On Monday, 13 June 2016 at 08:49:55 UTC, Guillaume Piolat wrote:
> This thing helps with getting rid of such bugs.

I suppose. The real cause of the bugs is not destructors I think, 
but memory corruption. Since frees (and double-frees) are 
deferred so long, it's just impossible to even guess at where the 
double destruction happened, or when you dereferenced a null 
pointer and D didn't catch that... again.

For those bugs, it would really help to know which objects are 
being freed, so you can check whether you accidentally forgot to 
initialize them or whatnot. Debugging their destructors is not 
the issue, and if it were I could just add a break inside the 
destructor itself.

> Having a non-trivial destructor called by the GC, and relying 
> on it, is imho an error at best, should always be manual.

I'd tend to agree. The reason I was using destructors at all is 
because I was using an SQL database. Those things like to act 
like whole global environments, where it's cheaper for you to 
create two tables within the same database than to have two 
databases open simultaneously, so usually when working with SQL I 
will make the database a global object, initialized on demand. 
Since there is *always* a database object, you can write code 
that can be optimized at compile-time, instead of code that runs 
conditionally at runtime, on the worthless check of whether it 
gets passed a database object or not.

So, the only problem is if the database is guaranteed to be open 
and usable anywhere in your code, when do you close it?

What I do is explicitly close it, then add a close() in the 
destructor with a warning. And then I run into GC errors... 
despite the only destructor in my entire program finishing 
without error.