[Issue 10344] Exiting _Dmain should flush all FILE*s and return nonzero on failure

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Jun 17 08:28:31 PDT 2013


http://d.puremagic.com/issues/show_bug.cgi?id=10344



--- Comment #10 from Steven Schveighoffer <schveiguy at yahoo.com> 2013-06-17 08:28:30 PDT ---
(In reply to comment #9)
> 
> But this is an argument against our current approach to stdout (we check and
> throw on all errors).

Yes, but there is a difference -- the error occurs DURING program execution.

In fact, one could diligently check for exceptions (and throw them away because
output isn't critical) on every writeln, but still have this unexpected error.

> The error in the program you mentioned may very well
> intervene in writeln under one or more of the following conditions:
> 
> * sufficient characters output

My post specifically said this is not the case.  a simple output message like
"X rows updated" will never exceed 4096 characters.

> * line buffered or unbuffered stdout

The conditions that cause this error preclude having stdout decide to flush on
newlines (a console is neither an invalid descriptor, nor in danger of running
out of space).

> In such cases, succeeding to produce stdout is just as unimportant to the
> program, but the program will fail with nonzero error code. Are you saying we
> should change that?

No, the program has not decided what it will return at that point.  It's a
standard exception, and if unhandled, that is a bug, or expected case in the
program (that should be documented).  I agree it's unlikely for most developers
to handle failed stdout, but it's reasonable that a diligent and careful
programmer will wrap his entire program in a try-catch block, and expect all
exceptions to be handled by that block.

> At the highest level, it is well understood there examples can be given that
> show the stdout output was of small consequence to the program. The point is we
> cannot decide on behalf of the program that it's okay to have truncated output.

I don't think we can decide either way.  At the time this flush occurs, the
program has made a concrete decision of success or failure.  Overriding that
decision is not something the runtime should be doing.

Consider the case where the filesystem driver fails to finish writing the file
after the program exits.  How do we handle that?

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


More information about the Digitalmars-d-bugs mailing list