Exception lib proposal update: exception_info name collision
Hello, I forgot to mention that windows.h defines a macro called exception_info which causes obscure compile errors with the proposed boost exception library (http://www.revergestudios.com/boost-exception/boost-exception.htm). My own solution to this issue was to #undef exception_info after including windows.h, but I realize that the easiest solution to this problem is to rename the exception_info function in the exception lib. I'm thinking of renaming it to xinfo but I'd like to consider other ideas as well. Thanks, Emil Dotchevski
Since I try to merge some of my libraries into one with a common exception concept I decided to use your exception library for it. After adapting the most complex exceptions to your system I have some suggestion to make: 1. Regarding the collission problem with a MS macro: The name xinfo is in my opinion a bit to general. Since english, as many european languages, borrows heavily from latin the prefix "ex" is quite common. And because xinfo is going to reside directly in the boost-namespace that may cause problems. Have you considered changing the info-part like exception_detail or exception_property? 2. For some reason you have decided to prohibit copy assignment (the copy assignment operator is private). Since I can't see a good reason for it, in fact I expect an exception to be assignable, I suggest you allow it. 3. I find myself writing a lot of wrapper function to retrieve the values from the exception. Since at the end eventually a message has to be displayed for the user I have to assume that certain tags have been added to the exception. So I try to get the tag-value and if it's not present replace it with a default value. Therefore I suggest a function like: template <class Name,class T> typename const exception_info_type<Name>::type& get_exception_info1( T const & some_exception ) { if (const exception_info_type<Name>::type* value = boost::get_exception_info<Name>(some_exception)) return *value; return Name::GetDefaultValue(); } so you can define tags like: struct tag_test : boost::exception_info_value<std::wstring> { static const value_type &GetDefaultValue() { const static std::wstring default_value(L"Unknown Value"); return default_value; } }; Of course "get_exception_info1" shouldn't be the name of the function. Actually I think the current "get_exception_info" should be renamed to "get_exception_info_ptr" and "get_exception_info1" should become "get_exception_info". Maybe optionally an assertion can show up in debug mode to remind the programmer that a tag is missing. Generally I can say that adding new functionality to exception is quite easy and repeated adding of common values can be nicely done in one function. The drawback is that the throw statements can get rather long and it's not possible to add a tag-value in the constructor. Best Regards Christoph
participants (2)
-
Christoph Krc -
Emil Dotchevski