On Thursday, 4 June 2015 at 16:49:07 UTC, Adam D. Ruppe wrote:
On Thursday, 4 June 2015 at 16:32:39 UTC, Etienne Cimon wrote:
Wouldn't that be with `this() in { assert() }` ?
Not necessarily. Consider something like a file wrapper, if
fopen is null inside the ctor, you'd generally throw on that.
My concern is the fact that the destructor won't be called. Or
will it?
It won't be for deterministic objects (structs on the stack)
but is for GC'd objects (eventually).
I don't think it should be called since if the constructor
fails, the object doesn't really exist and there's nothing to
destroy. You can reliably clean up intermediate things in a
constructor using scope(failure):
struct Foo {
FILE* file, file2;
this(something somename) {
file = fopen(somename);
if(file is null) throw FileException(somename);
scope(failure) { fclose(file); file = null; }
file2 = fopen(somename2);
if(file2 is null) throw FileException(somename2);
}
~this() {
if(file !is null) fclose(file);
if(file2 !is null) fclose(file2);
}
}
That'd work whether the destructor is called automatically or
not and isn't too hard to write since scope(failure) is pretty
convenient.
Nice, I'll try and use that once I find the reason I get this
error:
https://travis-ci.org/etcimon/botan/jobs/65410185#L426
Somewhere random in a 100k line code base, a deadlock is
triggered in the GC by some object's destructor. :/
