Bug 2545 – write(f)(ln) delays throwing StdioException("Bad file descriptor") when no console is available

It throws an exception at first call to flush when no stdout is a available (e.g. code compiled for SUBSYSTEM WINDOWS) and it causes some problems for GUI apps. I believe it should fail immediately (at the very first call to write) or (preferably) never fail at all. Otherwise, it leads to problem that are hard to track (e.g. all the unittests pass, but an application fails silently with no reason after a few hours of execution). I think its behavior should be close to printf which suppresses an error and goes on. Test code: import std.stdio; void main() { while(true) { //printf("!"); // works forever write("!"); // fails at first call to flush } }

How can it never fail at all? Or are you confusing "fail" with "throw an exception"? In any case, failing silently is completely the wrong approach. If there is no stdout to write to, it should throw an immediate exception. That's what exceptions are there for. printf doesn't suppress errors. It returns a value that indicates success or failure. This is because C doesn't have exception handling, and so C functions have to improvise. In D, OTOH, the only right thing to do is use exceptions to indicate failure. http://www.digitalmars.com/d/1.0/errors.html

Currently write forwards calls to the corresponding system routines and faithfully transforms their error codes into exceptions. I agree with Steward that non-failure is not an option :o), but I also agree that this state of affairs may also cause problems. I could put a check in write to make it fail sooner, but I'm thinking that maybe that behavior on Windows is intentional, e.g. to allow users to create their own console and flush to them or whatnot.

(In reply to comment #2) > Currently write forwards calls to the corresponding system routines and > faithfully transforms their error codes into exceptions. I agree with Steward I meant Stewart, sorry. -- Andrei

(In reply to comment #2) > I could put a check in write to make it fail sooner, but I'm thinking that > maybe that behavior on Windows is intentional, e.g. to allow users to create > their own console and flush to them or whatnot. What do you mean by this?

I think the behavior is as designed now. If not, please reopen.