Thread overview
[Issue 2545] New: write(f)(ln) throws StdioException("Bad file descriptor") when no console is available
Dec 29, 2008
d-bugmail
[Issue 2545] write(f)(ln) delays throwing StdioException("Bad file descriptor") when no console is available
Dec 29, 2008
d-bugmail
Dec 29, 2008
d-bugmail
Dec 29, 2008
d-bugmail
Dec 29, 2008
d-bugmail
December 29, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2545

           Summary: write(f)(ln) throws StdioException("Bad file
                    descriptor") when no console is available
           Product: D
           Version: 2.022
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: 2korden@gmail.com


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
    }
}


-- 

December 29, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2545


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
            Summary|write(f)(ln) throws         |write(f)(ln) delays throwing
                   |StdioException("Bad file    |StdioException("Bad file
                   |descriptor") when no console|descriptor") when no console
                   |is available                |is available




------- Comment #1 from smjg@iname.com  2008-12-29 10:21 -------
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


-- 

December 29, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2545





------- Comment #2 from andrei@metalanguage.com  2008-12-29 12:06 -------
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.


-- 

December 29, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2545





------- Comment #3 from andrei@metalanguage.com  2008-12-29 12:07 -------
(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


-- 

December 29, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2545





------- Comment #4 from smjg@iname.com  2008-12-29 13:42 -------
(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?


-- 

October 11, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2545


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei@metalanguage.com
         AssignedTo|nobody@puremagic.com        |andrei@metalanguage.com


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 26, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=2545


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #5 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-09-26 12:07:13 PDT ---
I think the behavior is as designed now. If not, please reopen.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------