[merge][#135241] better handling of internal errors in blackbox tests

[Martin Pool]

This changes the way that TestCase.run_bzr handles internal errors.
Previously they would be caught and turned into a traceback on the
captured stderr in the usual way.  This is not so good because:

 - in general blackbox tests should never get a traceback, except for
a few that are specifically testing how unexpected errors are
presented
 - the test results are cluttered with two tracebacks per failure
 - in general the actual failure is less accessible, if we want to for
example run pdb on it

As a minor proof of its usefulness this caught a NameError in the new
cmd_reconfigure -- the tests were hitting this error but not detecting
that it was a problem.

In passing this also cleans up some deprecated code from TestCase.

This should unblock https://bugs.launchpad.net/bzr/+bug/135421
"different exit code for internal errors" but I haven't merged in the
code to actually set the error code yet.

This highlights some unresolved problems in handling of unicode data.
At commands can choose for their output to be sent in either strict,
exact, or replace mode.  exact mode means they always emit byte
strings (like bzr cat) and this is not a problem.  replace means that
unrepresentable characters are replaced, and that's also fine.  But if
a strict-mode command needs to write data that won't fit in the user's
encoding, it fails with a traceback.  test_non_ascii contains many
examples of these at present, and people hit them in practice from
time to time.  Needless to say we don't really want people getting
tracebacks.

Maybe it needs to be done case by case.  Here are some options:

* have no 'strict' command output: every command either emits bytes,
or tolerates having unrepresentable characters replaced -- but maybe
this is just pushing the problem down to the command?  This may have
the problem that the user will get a screenful of questionmarks, which
is not much better than getting a traceback.
* treat unicodeerror as a user error, and give a short and cleaner
message, maybe showing the locale -- but the user is still blocked
from whatever operation they were trying to do.
* assume that people commonly have an ascii locale when they can
actually tolerate utf-8, and go ahead and send that when we're not
willing to do replacement?

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20070918-error-traceback.diff
Type: text/x-diff
Size: 28058 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070918/7caf3cdf/attachment-0001.bin