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

[Maritza Mendez]

That would be a huge step toward reducing uninformed (yet
understandable) user anxiety *and* still get the feedback needed to
get bugs reported and fixed.

~M


On 8/11/09, Martin Pool <mbp at canonical.com> wrote:
> 2009/8/11 James Westby <jw+debian at jameswestby.net>:
>> Martin Pool wrote:
>>> 2- I agree with Russel we should only log the exception by default,
>>> though having a means to turn it on (like -Derror) only for unexpected
>>> errors would be good.  This would implicitly fix some bug reports
>>> about eg socketerror causing a traceback - it will still be not ideal
>>> that we just say "no route to host" but it looks better.
>>>
>>> Does anyone disagree?
>>
>>
>> Sort of.
>>
>> I still think that it should at least include the stanza about filing a
>> bug on unexpected errors. Otherwise you get something like
>>
>>  $ bzr branch ...
>>  AbsentContentFactory has no attribute ...
>>
>> which is absolutely unhelpful, but presented as a message the user
>> should know how to deal with. The traceback and the instructions to
>> file a bug at least provide an indication that it is a bzr bug, rather
>> than user error.
>>
>> Error messages are hugely important for usability, and providing these
>> hints to the user is a great help with that, as we can't ensure that
>> there are no unexpected errors.
>>
>> It works against your point that it would make some bugs go away, but
>> it's not really the right way to fix them anyway.
>
> That's a really good point.
>
> How about if we said something like this
>
> $ bzr branch....
> AbsentContentFactory has no attribute...
> This probably indicates a bug in Bazaar.  Sorry.  For help or to
> report a bug see http://bazaar-......
>
> Also and separately, "we have a problem in streaming" should at least
> say so, not just raise an AttributeError, but that's orthogonal.
>
> --
> Martin <http://launchpad.net/~mbp/>
>
>