On Mon, Feb 23, 2009 at 10:38 PM, Lian Cheng
Thanks a lot for the recipe! But the asynchronous MySQL API I'm working on is based on Asio, which uses Boost.System for error handling. Boost.System provides a unified method to handle errors with both traditional error code paradigm and the exception paradigm.
I am not familiar with Boost Asio, but as long as it reports errors by throwing exceptions through boost::throw_exception (which most Boost libraries do), you can use a modified version of the recipe I posted. This is because any exception emitted by boost::throw_exception is guaranteed to derive boost::exception, which lets you intercept it and inject information relevant to the failure, even if that information wasn't initially stored by the code reporting the error. See "Adding of Arbitrary Data to Active Exception Objects" in http://www.boost.org/doc/libs/1_38_0/libs/exception/doc/tutorial_transportin....
Thus, there may be code like this: <snipped> I think Boost.System should allow user to pass into a function object instead of a single error code to the error_category::message() function, so that user can have better control on error message generation policies.
The question is where do you draw the line? There are use cases for which a function object wouldn't be enough. In fact, what data has to be stored in an error reporting object (such as boost::system::error_code or an exception) cannot be determined by the designers of the library that reports the error, because the user context in which the error occurs is not known but is very much relevant. For example consider an XML parser that detects and reports a parsing error: in general, it doesn't know if the XML it parses comes from a file or from somewhere else, but if it comes from a file, the file name is certainly relevant to the failure. This common problem was the motivation for Boost Exception and has lead to a design that lets users store anything at all into exception objects. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode