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