stdio: raise StdioError if something goes wrong in ui.flush The prior code used to ignore all errors, which was intended to deal with a decade-old problem with writing to broken pipes on Windows. However, that code inadvertantly went a lot further, making it impossible to detect *all* I/O errors on stdio ... but only sometimes. What actually happened was that if Mercurial wrote less than a stdio buffer's worth of output (the overwhelmingly common case for most commands), any error that occurred would get swallowed here. But if the buffering strategy changed, an unhandled IOError could be raised from any number of other locations. Because we now have a top-level StdioError handler, and ui._write and ui._write_err (and now flush!) will raise that exception, we have one rational place to detect and handle these errors.

stdio: raise StdioError if something goes wrong in ui._write_err The prior code used to ignore certain classes of error, which was not the right thing to do.

stdio: raise StdioError if something goes wrong in ui._write

stdio: catch StdioError in dispatch.run and clean up appropriately We attempt to report what went wrong, and more importantly exit the program with an error code. (The exception we catch is not yet raised anywhere in the code.)

stdio: add machinery to identify failed stdout/stderr writes Mercurial currently fails to notice failures to write to stdout or stderr. A correctly functioning command line tool should detect this and exit with an error code. To achieve this, we need a little extra plumbing, which we start adding here.

atexit: switch to home-grown implementation