Re: [Boost-users] [boost::system] Is the library abstraction general enough?

Subject: Re: [Boost-users] [boost::system] Is the library abstraction general enough?
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-02-24 02:13:57

On Mon, Feb 23, 2009 at 10:38 PM, Lian Cheng <rhythm.mail_at_[hidden]> wrote:
> 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_transporting_data.html.

> 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