"Emil Dotchevski" wrote: "Pavel Vozenilek" wrote:
1. As mentioned above, the ability to iterate through values and/or pass a visitor. <snip> Use case for iterator over values: I may want an automated checker that verifies that exception A contains only somewhere specified values and nothing else.
The "and nothing else" part can not be implemented on top of the proposed framework. OTOH, it is not very practical because it is very common for boost exception objects to contain additional information unknown to a particular context. For example, there might be platform-specific debugging information which shouldn't render an exception object invalid.
If you don't insist on "and nothing else", what you want can be implemented without adding iteration to Boost Exception.
Let say we disagree here. I see iteration (or less conveniently visitation) as a useful mechanism for not-yet-designed tools that would automatically process, convert or check validity of exceptions
4. I would like the ability to collect traces generated by what() function in DEBUG mode, something as: <snip>
Would this work for you:
struct tag_debug_trace: boost::error_info<std::string> { };
void add_debug_trace( boost::exception & e2, boost::exception & e ) { #ifdef _DEBUG if( !boost::get_error_info<tag_debug_trace>(e2) ) e2 << boost::error_info<tag_debug_trace>(""); (*boost::get_error_info<tag_debug_trace>(e2)) += e.what(); #endif }
and then:
catch (my_low_level_exception& e) { my_high_level_exception e2; ... fill in e2 add_debug_trace(e2,e); throw e2; }
Yeah, something like that with visual separation between different exception objects and as a standard part of the library.
I mean, this type of functionality is often application-specific and is best left out of the Boost Exception specification, in my opinion. This was just an illustration that what you want can already be done using Boost Exception.
Three points: 1. If it is in Boost there's no need to create it, it would be documented and always available 2. If it gets semi-standardized in Boost it would be much more likely used than a home grown equivalent. If everyone creates their own mechanism cooperation would not be smooth. 3. It doesn't prevent application specific solution. /Pavel