[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Error reporting capabilities for libxc
On Mon, Oct 23, 2006 at 11:15:21PM +0100, Ian Pratt wrote: > > > Would we be better off returning an error code and a set of > parameters, > > > requiring a call-back into the library to get the string? > > > > That assumes that there is a static mapping between an error code > > and the error description, which there isn't. The error description > > can contain info about actual bits of metadata which were incorrect. > > For example when reporting an invalid ELF architecture, it can tell > > you exactly what ELF arch was found & what was expected. > > That's precisely my point. The various bits of metadata can be > parameters passed back along with the error code. It's possible that > some callers will be able to do things with the metadata that are more > useful than just printing the string. I guess the error parameters could > be returned as a va_list. Many callers would just call back into the > library to get the appropriate error string. Ahh, I mis-read your comment a little. That is certainly one possibility although I'm not entirely a fan of va_list as an API - perhaps either a struct with a handful of generic data fields for returning metadata, or a union switched on the error code would work - it'd be nice to be able to copy all the bits around without needing memory allocation in any of the error handling paths. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |