RFC: startup time - again

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On Tue, Sep 9, 2008 at 8:50 PM, Andrew Bennetts <andrew at canonical.com> wrote:
>> Robert Collins wrote:
> Having the entry point in C rather than in Python, and eventually
> transitioning to running some commands without a Python interpreter at
> all.  It's nontrivial to get there, if you want to keep all our
> extension points for plugins, transports, formats, etc.  And just
> starting Python is not the largest issue.

I would much rather work on a Python project with C extensions than a C
project with Python extensions.

> I would say also we should be a bit smarter about when we add a new
> error class; I've mentioned it in reviews but should probably put up a
> coding standard patch.
> 
> 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.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIxnXs0F+nu1YWqI0RAk9IAJ0UIsXY79zwvWVlJMwN031POYa9CwCfa+IY
1CnMr4Oq1Mr/6JW7MJrgxL0=
=j4CI
-----END PGP SIGNATURE-----