Bad file descriptor in File destructor

[Moritz Maxeiner via Digitalmars-d-learn]

On Thursday, 13 July 2017 at 10:28:30 UTC, unDEFER wrote:
> On Thursday, 13 July 2017 at 08:53:24 UTC, Moritz Maxeiner 
> wrote:
>> Where does that `File` come from? If it's std.stdio.File, that 
>> one is a struct with internal reference counting, so it 
>> shouldn't crash in the above. Could you provide a minimal 
>> working (in this case crashing) example?
>
> Yes File is std.stdio.File. And I can't provide a minimal 
> crashing example because this code crashes very rarely.
>
> I just want to put try/catch and don't know where to do it.

Well, if you get an ErrnoException on std.stdio.File.~this you 
are AFAIK either encountering an OS bug, or you have previously 
corrupted the file descriptor that File instance wraps around. To 
be specific, it sounds to me like you're trying to close a file 
descriptor that's already been closed, i.e. you should fix that 
instead of trying to work around the consequences of it.
Under the assumption, though, that it's an OS bug you're 
encountering, you can't deal with it with just a try catch in 
that function, because a (stack allocated) struct's destructor is 
always called when it goes out of scope.
I see essentially two workarounds:
- Use two functions foo and bar, where bar has `file` on it's 
stack, and `foo` calls `bar` and catches the destructor exception 
via try catch block around the call to `bar`
- Hide the `file` from the automatic out-of-scope destruction by 
using another type for storage

Personally I'd prefer the second variant, it could look like this:

---
ubyte[File.sizeof] _file;
ref File file() { return *(cast(File*) &_file[0]); }
[create File instance and assign to file]
scope (exit) destroy(file);
---