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