RFC: startup time - again

[Martin Pool]

On Tue, Sep 9, 2008 at 11:11 PM, Aaron Bentley <aaron at aaronbentley.com> wrote:
>> Adding a new class is a good way to let calling code (in bzrlib or
>> elsewhere) distinguish that particular error case and catch it.
>>
>> If the exception indicates a code bug and is not intended to be
>> caught, it doesn't need a specific class.  AssertionError, ValueError,
>> etc, is enough.
>>
>> If the error is different only in that it gives a different message to
>> the user, it also doesn't need a new class.
>
> I don't think it costs very much to define all the errors that a given
> codepath may raise.  I think we should consider defining errors near the
> code that will raise them, rather than in a monolithic errors module.
>
> I agree with Robert that code which catches errors should be able
> distinguish between errors according to the class, rather than having to
> use string matching or error numbers or something like that.

Hang on, both of you cut off my mail just before the point where I
specifically mentioned errors that may be both shown to the user and
caught by code... :-)  I agree that calling code should not need to
parse the string.

I agree one option is to put errors near the raising code, on the
grounds that it will very likely be loaded if someone wants to catch
the error.

My point is that if a new class is actually unnecessary altogether
that avoids even thinking about this.

-- 
Martin <http://launchpad.net/~mbp/>