
Hello, 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 have received two suggestions by email to remove the use of macros for type registration. Currently, to register tag_foo with the exception library, and to specify that its value is of type int, you'd use: BOOST_REGISTER_EXCEPTION_INFO(tag_foo,int) One suggestion was to use this instead: struct tag_foo { typedef int value_type; }; Another suggestion was very similar, with the following syntax: struct tag_foo: exception_info_tag<int> { }; I encourage everyone to provide your feedback in the mailing list instead of by email, so we can have an open discussion. Thanks, Emil Dotchevski

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.
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: ------------------------------------------------------------------------- // Base class for exception information tag/value pairs. struct exception_info_wrapper_base { // Method to describe information tag/value pair // in a human-readable form. virtual void print(std::ostream& os)=0; // Virtual destructor so that value deletion works properly. virtual ~exception_info_wrapper_base() {} }; // Store an exception information tag/value pair. template <class Tag> struct exception_info_wrapper: exception_info_wrapper_base { // Get the information value type from the tag. typedef typename Tag::value_type value_type; // Construct with an exception information value. explicit exception_info_wrapper(value_type const& value): value_(value) {} // Store the exception information value. value_type value_; // Forward a print request to the static method provided by the tag. virtual void print(std::ostream& os) { Tag::print(os, typeid(Tag), value_); } }; // Base class for exception information tags. template <class T> struct exception_info_tag { // Type of value associated with the tag. typedef T value_type; // Default implementation of tag/value pair display. static void print(std::ostream& os, std::type_info const& t, value_type& value) { os << "Tag " << t.name() << " with value \"" << value << "\""; } }; // Example tag using default pair display. struct my_example_tag1: boost::exception_info_tag<int> {}; // Example tag using custom pair display. struct my_example_tag2: boost::exception_info_tag<double> { static void print(std::ostream& os, std::type_info const&, value_type& value) { os << "Custom print of example tag 2: " << value; } }; ------------------------------------------------------------------------- Now the exception object can loop through its map and invoke the virtual print method on each entry. This could be useful for debugging or when the set of potential information entries is not known and a message describing the error is desired. -Brad

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
participants (2)
-
Brad King
-
Emil Dotchevski