RFC: remove traceback from "newer branch format than your bzr"

[Eric Siegerman]

On Tue, 2009-08-11 at 15:14 +0200, Jelmer Vernooij wrote:
> Strack traces are the equivalent of segmentation faults in Bazaar,
> when they are displayed there is *always* a bug, never expected
> behaviour. 

To amplify on this, the goal (as this non-bzr-developer
understands it; please correct and/or clarify if appropriate), is
that users should *never* receive tracebacks.  If you get one,
it's a bug in bzr.

Sometimes, a traceback indicates a situation that "should never
occur" (i.e. the bug lies in whatever caused the situation in the
first place).

Other times, as in this case, it's an error condition that *can*
occur in (more or less) normal use, but is not being properly
handled when it does (i.e. the bug is in the error-handling code
itself).  Examples would be network problems, version mismatches,
user errors, etc.  All of those are to be expected from time to
time, but none should result in a traceback.

So either way, the fact that you get a traceback indicates a bug
in bzr itself, above and beyond whatever "expectable" condition,
if any, might have triggered it.

Of course, bzr will probably never achieve the goal of "no
traceback-causing bugs, ever".  Old bugs are fixed, but new ones
are introduced.  Fact of life.  The original post has led to some
interesting discussion about better ways of presenting such
errors to the user than just dumping a stacktrace on stderr, and
of encouraging the user to file bug reports (or doing so for
them).

  - Eric