Allow multiple sql::Connection error delegates.

[Closing because I think later developments obsoleted this.]

Allow multiple sql::Connection error delegates.

This seems like a cleaner solution than chaining.

BUG=none

[erikwright (departed), 2012-10-12 18:59:28]

Can you express what's wrong with composition via wrapping?

Having a list of error observers implies that you have some protocol for how you
call them in order. And what happens if one of them acts to resolve the problem,
etc?

Allowing clients to compose an error delegate according to their needs seems
safer and perfectly reasonable.

[Scott Hess - ex-Googler, 2012-10-12 19:41:17]

On 2012/10/12 18:59:28, erikwright wrote:
> Can you express what's wrong with composition via wrapping?
> 
> Allowing clients to compose an error delegate according to their needs seems
> safer and perfectly reasonable.

Wrapping is implicitly nested, so the earlier items cannot safely remove
themselves from the chain.  Wrapping messes with the ownership hierarchy (the
connection and all other refs could be removed, but the wrapper itself could
maintain a ref to the original handler, and have a distinct lifetime). 
Intrusively wrapping the original handler can break assumptions in the original
handler.

> Having a list of error observers implies that you have some protocol for how
you
> call them in order. And what happens if one of them acts to resolve the
problem,
> etc?

Wait, what?  It's exactly the same as your wrapped version, it's forwarded until
someone handles it.

As I said elsewhere, it would maybe be more satisfying to just have the
single-level delegate adapt to do all the jobs necessary.  I generally am
against the pattern of registering arbitrary interest all over the place, like
notifications and observers.  If I had time I'd just inline the histogram stuff
directly (sql::Connection could have a histogram prefix), which would get rid of
damn near all of the existing delegates.