Re: [boost] [review] Exception

From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-10-22 14:59:22

> <snip>
> Other (over-)optimizations that may be considered:
>
> * some to-string conversions could be handled w/o stringstream

This can be done without altering the proposed interface.

Boost Exception uses an unqualified call to to_string to convert an
error_info value to string (for automatic inclusion in the what()
message.) The user also has the option of disabling the to_string
conversion at the point when a tag type is registered.

Currently, Boost Exception contains a generic to_string overload which
attempts to use an ostringstream object to do the conversion. However,
this is just an implementation detail.

> * if it is applicable (I didn't measured) code bloat caused by
>   inlining on slow paths may be reduced for MSVC compiled
>   by using __declspec(noinline).

Yes, other platform-specific optimizations and additions (such as
automatic stack trace) are also possible within the proposed
framework.

> >> 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.

> >> 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.

Emil Dotchevski