Re: [boost] [review] Exception

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2007-10-23 13:02:47

"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