D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 2545 - write(f)(ln) delays throwing StdioException("Bad file descriptor") when no console is available
Summary: write(f)(ln) delays throwing StdioException("Bad file descriptor") when no co...
Status: RESOLVED WONTFIX
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D2
Hardware: x86 Windows
: P2 enhancement
Assignee: Andrei Alexandrescu
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-29 09:29 UTC by Koroskin Denis
Modified: 2015-06-09 01:20 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Koroskin Denis 2008-12-29 09:29:13 UTC
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
    }
}
Comment 1 Stewart Gordon 2008-12-29 10:21:18 UTC
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
Comment 2 Andrei Alexandrescu 2008-12-29 12:06:33 UTC
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.
Comment 3 Andrei Alexandrescu 2008-12-29 12:07:12 UTC
(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
Comment 4 Stewart Gordon 2008-12-29 13:42:12 UTC
(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?
Comment 5 Andrei Alexandrescu 2010-09-26 12:07:13 UTC
I think the behavior is as designed now. If not, please reopen.