On Thu, Feb 05, 2009 at 08:39:55PM +0000, Daniel P. Berrange wrote:
> First, we'd need to make some changes to the libvirtd
because it calls
> into a number of APIs, both public entry points & some of the internal
> helpers directly, but does not reset the error in betweeen these calls.
> Of course it also doesn't actually do anything with errors that these
> calls may raise - they just happen to be printed on stderr. If we only
Right, I think I mentioned there were some cases where we would need
special handling. Hopefully they're easier to find and fix than the
reverse case, though I don't have any good ideas how.
> As you point out it is pretty hard to get this right and/or
identify
> places where it is wrong. As a starting point, though adding code to
> virRaiseError which prints a stack trace to stderr() whenever it is
> called with an error already set, would help our awareness. Obviously
> this would only want to be turned on in dev-builds.
That would help. The problem is this though: the worst possible errors
to lose are those rare one-off events that happen in production, and
they're precisely the ones least likely to be caught during testing.
I wonder if we need to abandon the notion of a single error altogether,
and maintain a stack of them across each top-level call.
regards
john