[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.
Vincent
More information about the bazaar
mailing list