Exception mangling in hooks?

[Andrew Bennetts]

Stephen J. Turnbull wrote:
> James Westby writes:
[...]
>  > > There's a limit to how much we can protect bzrlib against
>  > > plugins.  New branch formats like bzr-loom's integrate at a very
>  > > deep and pervasive level, so the best we can realistically do for
>  > > that case is something like tweak bzrlib.trace.report_bug to
>  > > examine the traceback we're about to show the user and modify our
>  > > ~Please report a bzr bug~ message to be a bit more ambivalent if
>  > > ~bzrlib/plugins~ appears in the traceback.
> 
> I don't think that's very useful.  The user should be briefly invited
> to report an issue for anything that they don't understand.  If the
> user is of the type that is going to investigate for themselves,
> they'll do that anyway.  You might want to add a comment that "Since
> the bzlib/XXX and foobar/YYY plugins are involved in the backtrace,
> you should also report this error to the bzrlib and foobar
> developers."  (Or something appropriate to the structure of the
> projects.)

Actually, we agree :)

I didn't mean the message should be ambivalent about asking for a bug
report.  I meant that it should be ambivalent about where to direct the bug
report, because it's about as likely to be a problem with the plugin rather
than bzr itself.

As James says, it's not a large burden to redirect the occasional misfiled
bug.  But if a user is told that hook X from plugin Y failed, that is more
likely to be helpful to them than a generic traceback, and makes it more
likely they can fix our workaround their issue without waiting for a
diagnosis of their bug report.

[...]
> A more effective approach would be
> 
>     "This error indicates you may have encountered a bug in bzr or a
>     plugin.  Response to your issue will be faster, more accurate, and
>     more effective if you follow the guidelines in 'Reporting bzr
>     Bugs' in the User Guide.  Please report this issue to <URL>."[1]
> 
> with a prominent section explaining the consequences (not the analysis
> techniques! if desired, that can be a separate subsection for advanced
> users) of plugins for bug reporting and resolution in the Bazaar process.

Perhaps, although finding and reading a separate document adds another step,
which makes it less likely that the user will go through with filing the
bug.  It's a tradeoff.

>  > I'm not sure we need to change anything there do we? I think currently
>  > the cost of re-assigning the few bugs, or closing them for local 
>  > plugins,
> 
> Couldn't that cost be lowered further with a Launchpad feature to
> analyze tracebacks and add attributes to the issue that indicate the
> presence (and to some extent the nature) of plugins in the traceback?
> This level of analysis is already proposed, so the extra effort to add
> such a feature to the tracker would amount to detecting the presence
> of tracebacks in the report.

That would be nice, although it's not a large burden for bzr yet.

>  > is outweighed by the fact that this helps our users get help with
>  > the problems.
> 
> Footnotes: 
> [1]  XEmacs actually has found it useful to go farther than that by
> emphasizing the importance of preserving any evidence such as core
> files and the backtrace itself, and including them in the report.

Our ~/.bzr.log somewhat takes care of this, but including the relevant parts
in a bug report could be made more automatic...

-Andrew.