> You're not reading carefully. I never said fclose() flushes anything. Please go back and read what I wrote. I did read, thanks. AFAICT, the POSIX standard m

> You're not reading carefully. I never said fclose() flushes anything. Please go back and read what I wrote. I did read, thanks. AFAICT, the POSIX standard mandates that fclose() must flush pending output, so what you said is immaterial. That is, it can fail to flush in exactly the way I mentioned, and so any destructor-like behavior is faced with a decision as to "what to do". Now, you're technically right in that the RESOURCE representing the file will be closed, but my counter-point was that it doesn't matter. Either the destructor swallows the error yielding silent incorrect behavior, or the destructor must throw and abort the program. Neither is very helpful, though I guess aborting the program doesn't play havoc with the program's meaning. My question is really: What does scope(exit) actually do if a fflush() fails, for example? Any non-built-in equivalent of "scope(exit)" in C++ would have to use a destructor to function reliably, I think, so what to do? Does it throw? When does it throw? Is it allowed to throw if we're already unwinding the stack due to another exception? This is horribly complicated... and that's my overall point, really. Just the fact that a resource was technically freed is moot if the program does the wrong thing. The horrible complicatedness of all of this is an indicator that something is deeply wrong. (Incidentally, in Java the try-with-resources statement actually seems to do at least a semi-sane thing which is that an exception during a "finally" clause attaches that exception to the already "active" exception in case it happens during unwinding from a thrown exception. Or the other way around, can't be arsed to look it up. The point is that unwinding happens, but errors are not lost. I'm not sure if it actually does the right thing wrt. file descriptors, but one hopes so.)