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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list