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

[Martin Pool]

2009/8/12 Alexander Belchenko <bialix at ukr.net>:
> John Arbash Meinel пишет:
>> Eric Siegerman wrote:
>>> 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.

Users should never see a traceback because they should never see a bug.

One step closer to reality, if they see a traceback it does mean there
is, as Eric says, a bug: in say ⅓ of cases it's the shallow (but still
real) bug that a problem situation is just not correctly reported,
like Emma's original example.

Sometimes we have the opposite which is that there's no traceback but
there is a bug.  The fact that the exception doesn't normally indicate
a bug doesn't mean there is not a bug in this case - things like
problems using proxies causing "network unreachable" errors.  And this
is leaving aside bugs that don't relate to an exception at all.

If there's a bug we should default to people reporting it, ideally
without doing extra round trips to get more information.

There's no point in someone _reading_ a traceback if they're not able
or willing to debug the failure.  At the moment we make them see it or
read it as a somewhat clumsy way to make them file the bug with enough
data.  People mostly do comply; at least they do this much more often
than before we had it.

>> Another possibility is to never show tracebacks but integrate better
>> with apport. Which could allow us to save the traceback off to the side,
>> and gives a nice prompt to the user to submit this stuff to launchpad.

Right, connecting to and if necessary improving apport is much better
than reinventing it.

> apport works on Windows?

It's pure Python.  It should work there, or at least not be too hard to fix.

So it seems to me that if we used Apport it would have these consequences:

Users would get the nice "do you want to report this? yes/no/shut up"
dialog box.  (But only in gui mode- they can file the crash report
manually, or we could specifically ask if they want to do this before
bzr exits.)

It would give us some more features, such as automatically recording
the versions of depended-upon packages.

We'd need to package it in the installers etc, and package it on
systems like Fedora where it may not be shipped at the moment.

People would be sent to Launchpad to file bugs, but that's true at the
moment.  They'd still have the option to send the crash file to the
list.

We'd possibly get better de-duplification.

Developers would probably want a way to turn it off and just see the traceback.

It doesn't particularly help with bugs that don't cause a crash or
that are incorrectly thought to be environmental or user errors, but
it doesn't particularly hurt.

It might fight a bit with Ubuntu or other distros use of apport, but
again it can probably be resolved.

-- 
Martin <http://launchpad.net/~mbp/>