[RFC] Allow error definitions outside bzrlib.errors?

Vincent Ladeuil v.ladeuil+lp at free.fr
Tue Aug 11 09:00:42 BST 2009

>>>>> "martin" == Martin Pool <mbp at canonical.com> writes:

    martin> 2009/8/11 Andrew Bennetts <andrew.bennetts at canonical.com>:

    >> For a long time our policy has been that error definitions
    >> belong in bzrlib.errors.  This has been very convenient,
    >> but we've also found that it's a wasteful to have every
    >> invocation of Bazaar execute the definitions of over 300
    >> error classes when most invocations will use virtually
    >> none of them.  The cost isn't huge (roughly 20ms according
    >> to a quick-and-dirty benchmark on my laptop), but it's
    >> large enough that we've become reluctant to keep adding to
    >> errors.py.
    >> So, I propose we relax the policy a little.  I suggest we
    >> allow defining some errors inside the modules that raise
    >> them, for errors that:
    >>  a) raised only by one module, and

    >>  b) typically the only places that explicitly catch that
    >> error are the     immediate callers of that
    >> module.  (“explicitly” meaning caught via “except    
    >> ExactErrorName” or similar, rather than catch-alls like
    >> the one found in     run_bzr_catch_user_errors).

    martin> That sounds ok to me.

Right, but the proposal is still to defined such errors as
inheriting from BzrError right ?

So the payoff will only be when we clean bzrlib.errors from the
specific errors than can be declared in modules.

I'd really prefer that we keep *some* errors defined there if
only the generic ones.


More information about the bazaar mailing list