[merge] catching EPIPE (especially on win32)

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> This isn't how CVS works. If you ^C in the middle, you get:
>>> cvs [log aborted]: received interrupt signal
>>>
>>> I think it is fine for bzr to print
>>> bzr: interrupted
> 
> The original purpose of the display_command decorator was to swallow
> KeyboardInterrupt.
> 
> There are plenty of counterexamples of commands that don't print
> anything when interrupted.
> 
> The entire display_command distinction is that these commands don't do
> anything, so KeyboardInterrupt and EPIPE aren't dangerous and can't lead
> to errors.
> 
>>> swalling KeyboardInterrupt also means that when the test suite is
>>> running, you can't stop it with a simple ^C.
> 
> Perhaps we should rethrow it as SilentKeyboardInterrupt or
> PrettyKeyboardInterrupt, but the default handling of KeyboardInterrupt
> is dead ugly, and I don't think we want to use that.
> 
> Aaron

Is this because originally we didn't handle KeyboardInterrupt properly?
Now we just display 'bzr: interrupted' rather than a full traceback.

If you look at bzrlib.trace.report_exception()
We special case for EPIPE to print:
bzr: broken pipe
and KeyboardInterrupt to print
bzr: interrupted
(and then user errors are nice printed versus internal errors printing
the full traceback).

I think we have it handled in a reasonable way. Otherwise I would agree
with you that printing a traceback just because someone hit ^C in the
middle is a bit ugly.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEo0xCJdeBCYSNAAMRAujJAKCiDarlzKv77vpnl16ijgdoO5b77ACaAu0u
SXyucvEQtK5AVGHfTKSfi0w=
=cWhU
-----END PGP SIGNATURE-----