Exception mangling in hooks?

[Stephen J. Turnbull]

James Westby writes:
 > On Fri, 2009-02-27 at 21:50 +1100, Andrew Bennetts wrote:

 > > 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.)

For this to be effective, plugins should provide issue-reporting
addresses that the traceback can reference.

OTOH, if the user is not of that type, they will either report the bug
anyway, or conclude that Bazaar just doesn't care about support.  I
think that risk is quite high.

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.

 > 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.

 > 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.