Comment 0 for bug 123592

I've found at least 4 patterns for what the common SomeDatabaseObjectSet.get(id) methods do when the 'id' is not present:

1. nothing special, and thus raise SQLObjectNotFoundError. This doesn't seem that great an idea, though it's probably ok for methods that never expect to be called for a missing id (the id is never derived from user input, for example).

2. catch SQLObjectNotFoundError and reraise the launchpad specific NotFoundError.

3. return None.

4. ape the dictionary .get() method and return an optional second argument that defaults to None.

This seems a bit of a mess.

While 4 seems the most flexible, I think it's actually wasted effort: if you're after the database row with a particular id, it seems very unlikely that some other (non-None) object will do, and in my grepping I found exactly no code taking advantage of the flexibility of these methods (not even tests). Option 1 has clear disadvantages (exposing implementation details) and so the choice is between 2 and 3. I'd lean towards 2, following the 'making errors errors' Python tradition.