This is an update to the proposed boost::exception library (the source code, full documentation and tests are available at http://www.revergestudios.com/boost-exception/boost-exception.htm.) Last thing that I wanted to clear before requesting a formal boost review for boost::exception is renaming exception_info as a workaround for the name clash with the macro with the same name (lowercase and all) defined by windows.h. The two candidates I like for renaming exception_info are: except_info throw_info Here is an example of how they would look in code: throw my_exception() << except_info<tag_errno>(errno) << except_info<tag_function>(BOOST_CURRENT_FUNCTION); -or- throw my_exception() << throw_info<tag_errno>(errno) << throw_info<tag_function>(BOOST_CURRENT_FUNCTION); The above is a use case of encoding exception information at the time of the throw. The other use case is to catch a boost::exception, add exception info to it and re-throw. Here is an example of how each of except_info and throw_info would look in that case: catch( boost::exception & x ) { x << except_info<tag_filename>(fn); throw; } -or- catch( boost::exception & x ) { x << throw_info<tag_filename>(fn); throw; } Any strong preferences? Thanks, Emil Dotchevski
Emil, how about another choice (which is more consistent with TR2 Diagnostics Enhancements) : error_info throw my_exception() << error_info<tag_errno>(errno) << error_info<tag_function>(BOOST_CURRENT_FUNCTION); catch( boost::exception & x ) { x << error_info<tag_filename>(fn); throw; } Minh ----- Original Message ----- From: "Emil Dotchevski" <emildotchevski@hotmail.com> To: <boost@lists.boost.org> Sent: Wednesday, November 08, 2006 6:57 AM Subject: [boost] Exception lib proposal: renaming boost::exception_info snip
except_info throw_info
Here is an example of how they would look in code:
throw my_exception() << except_info<tag_errno>(errno) << except_info<tag_function>(BOOST_CURRENT_FUNCTION);
-or-
throw my_exception() << throw_info<tag_errno>(errno) << throw_info<tag_function>(BOOST_CURRENT_FUNCTION);
snip
catch( boost::exception & x ) { x << except_info<tag_filename>(fn); throw; }
-or-
catch( boost::exception & x ) { x << throw_info<tag_filename>(fn); throw; }
Any strong preferences?
Thanks, Emil Dotchevski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Send instant messages to your online friends http://au.messenger.yahoo.com
how about another choice (which is more consistent with TR2 Diagnostics Enhancements) :
error_info
throw my_exception() << error_info<tag_errno>(errno) << error_info<tag_function>(BOOST_CURRENT_FUNCTION);
catch( boost::exception & x ) { x << error_info<tag_filename>(fn); throw; }
Minh
Sounds good. It certainly makes sense to be consistent with TR2 Diagnostics Enhancements. Unless someone comes up with compelling reasons why renaming exception_info to error_info is a bad idea, I'll make the change this weekend. --Emil Dotchevski
throw my_exception() << throw_info<tag_errno>(errno) << throw_info<tag_function>(BOOST_CURRENT_FUNCTION);
The above is a use case of encoding exception information at the time of the throw. The other use case is to catch a boost::exception, add exception info to it and re-throw. Here is an example of how each of except_info and throw_info would look in that case:
Any strong preferences?
What about upcoming boost::system::error_code and boost::system::system_error (used to report os errors)? regards, Oliver
Oliver.Kowalke@qimonda.com 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_usag..., 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_both.... 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
Oliver.Kowalke@qimonda.com 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)?
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:
I would not introduce boost::exception stuff into boost::system.
throw enable_exception_info(system_error(....));
Maybe a better solution?! Oliver
participants (4)
-
Emil Dotchevski -
Minh Phanivong -
Oliver.Kowalke＠qimonda.com -
Zajo