Re: [boost] Boost Exception

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-07-31 23:21:52

Brad King wrote:
> Emil Dotchevski wrote:
>> I posted the new version of the proposed Boost Exception library last
>> Friday, you can get the new documentation and code here:
>>
>> http://www.revergestudios.com/boost-exception/boost-exception.htm.
>
> I've just briefly glanced through the current implementation and some
> of
> the discussion earlier on the boost list.  It looks pretty nice so
> far.
>
> If it is not mentioned already in the documentation you should add an
> explanation of why boost::exception does not derive from
> std::exception.
> I'm guessing it's so that enable_exception_info works for types that
> derive from std::exception without diamond inheritance.  User-defined
> subclasses of boost::exception can also derive from std::exception
> anyway.

Your guess is correct: enable_exception_info is designed to integrate the 
exception library with existing programs, where modifying the exception 
class hierarchy could introduce subtle and hard to detect bugs in existing 
exception handling code. Because such hierarchies commonly derive from 
std::exception, if boost::exception also derives from std::exception this 
would result in unwanted double inheritance. Thanks for the tip, I already 
added this explaination in the FAQ.

>> I have received two suggestions by email to remove the use of macros
>> for type registration.
> [snip]
>> struct tag_foo: exception_info_tag<int> { };
>
> This version will allow custom display of the complete set of
> information tag/value pairs in an exception object.  You'll have to
> convert the internal
>
>  type_info => any
>
> map to be
>
>  type_info => exception_info_wrapper_base*
>
> or something like that.  The code of interest might look like this:
[snip]

Something like this crossed my mind but I'm a bit concerned that this kind 
of functionality will result in efforts to design elaborate systems of tag 
types, with perhaps even more complex virtual function interface, because 
the ultimate goal is to be able to format a meaningful and friendly 
(localized) message for the user.

So, while I do see the value of being able to print detailed debug messages, 
I think that the program needs to be able to extract the boost::exception 
information without the help of such a system. When an exception is caught, 
the program needs to know what info is available in it, so it can make sense 
of it. If that's the case (and it should be), printing a debug message is 
trivially implemented.

OTOH, being able to dump in a debug log *everything* you have in a 
boost::exception is perhaps too useful to pass.

Thanks for your feedback,
Emil Dotchevski