On Wed, 23 Jul 2014, Doug Hellmann wrote:
That's bad enough, but much worse, this will catch all sorts of
exceptions, even ones that are completely unexpected and ought to
cause a more drastic (and thus immediately informative) failure
than 'something failed’.
In most cases, we chose to handle errors this way to keep the service
running even in the face of “bad” data, since we are trying to
collect an audit stream and we don’t want to miss good data if we
encounter bad data.
a) I acknowledge that you're actually one of the "elders" to whom I
referred earlier so I hesitate to disagree with you here, so feel
free to shoot me down, but...
b) "keep the service running" in the face of "bad" is exactly the
sort or reason why I don't like this idiom. I think those
exceptions which we can enumerate as causes of "bad" should be
explicitly caught and explicitly logged and the rest of them
should explicitly cause death exactly because we don't know
what happened and the situation is _actually_ exceptional and we
ought to know now, not later, that it happened, and not some
number of minutes or hours or even days later when we notice that
some process, though still running, hasn't done any real work.
That kind of "keep it alive" rationale often leads to far more
complex debugging situations than otherwise.
In other words there are two kinds of "bad": The bad that we know
and can expect (even though we don't want it) and the bad that we
don't know and shouldn't expect. These should be handled
differently.
A compromise position (if one is needed) would be something akin to,
but not exactly like:
except (TheVarious, ExceptionsIKnow) as exc:
LOG.warning('shame, no workie, but you know, it happens: %s', exc)
except Exception:
LOG.exception('crisis!')
This makes it easier to distinguish between the noise and the nasty,
which I've found to be quite challenging thus far.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
