Re: [boost] Exception lib proposal: renaming boost::exception_info

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-11-10 14:18:06

Oliver.Kowalke_at_[hidden] wrote:
>> throw my_exception() <<
>>     throw_info<tag_errno>(errno) <<
>>     throw_info<tag_function>(BOOST_CURRENT_FUNCTION);
>>
>> <snip>
>
>> Any strong preferences?
>
> What about upcoming boost::system::error_code and
> boost::system::system_error (used to report os errors)?

My example (above) was derived from 
http://www.revergestudios.com/boost-exception/boost-exception.htm#basic_usage, 
and it was only intended to visualize what that example would look like if 
exception_info is renamed to throw_info due to the name clash with the 
exception_info macro defined in windows.h (but see Minh's responce in which 
he proposes the name error_info, which I think is what I'm going with now.)

If I read you correctly, what you're saying is that if boost::exception is 
accepted, we need to think about integration with the rest of boost. For 
example, if boost::system::system_error derives from std::runtime_error (as 
it does now) and also from boost::exception, (someone correct me if I'm 
missing something) the definition of boost::system_error could be reduced 
to:

struct tag_system_error_code: exception_info_value<error_code> { };
struct tag_sytem_error_msg: exception_info_value<std::string> { };
struct tag_system_error_action: exception_info_value<message_action> { };
struct tag_system_error_category: exception_info_value<error_category> { };

class system_error:
    public std::runtime_error,
    public boost::exception
{
public:
    char const * what() const throw() //resolve ambiguity.
    {
        return boost::exception::what();
    }
};

Then, when throwing, we can write:

throw system_error() <<
    exception_info<tag_system_error_code>(ec)  <<
    exception_info<tag_system_error_msg>(msg) <<
    ... ;

depending on what information is available to us. This also allows contexts 
that are higher in the call stack to catch( boost::exception & ), encode 
additional information available to them and rethrow. The rationale for this 
is discussed here: 
http://www.revergestudios.com/boost-exception/boost-exception.htm#Q_why_bother.

It is also possible to keep the current definition of class system_error, 
and simply change throw statements to:

throw enable_exception_info(system_error(....));

This also enables contexts that are higher in the call stack to catch( 
boost::exception & ), add more values and rethrow, without interfering with 
code unaware of boost::exception.

--Emil Dotchevski