Exception mangling in hooks?

[Robert Collins]

On Thu, 2009-02-26 at 13:30 +1100, Andrew Bennetts wrote:
> 
> I'd prefer to keep this, I think it's useful.  It helps identify that
> it's a
> hook that has the bug, not bzr itself, and it also identifies in the
> message
> which hook is to blame. 

We can do that while re-raising the actual error; we have both a UI
object and a log that could be used.

>  And because HookFailed is not an internal_error,
> the user doesn't get a message telling them to report a bug on bzr
> just because they misconfigured a plugin.

They get this for all the other hooks; I don't see many(any?) bugs on
bzr itself because of this.

I think wrapping raised exceptions is generally a bad idea and look for
really strong justification to do so: Its really very hard to interpret
a mangled exception (no, I wasn't in pdb, it was a test failure)
compared to the original. At a *minimum* I'd want the real full log, not
the log-below-the-call-site to be reported. But essentially I don't get
why we need the complexity: A failure to set the tip means we didn't set
the tip in all cases: why does it matter whether it occured in a hook,
or in the actual setting logic itself? [Plugins are entirely capable of
raising a nicely formated error themselves, as the pass-through of an
expected error type in the calling loop shows].

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090226/7ef7f536/attachment-0001.pgp