Re: [boost] Most needed/desired features in C++

From: Hamish Mackenzie (boost_at_[hidden])
Date: 2002-02-18 12:50:13

On Mon, 2002-02-18 at 16:37, Peter Dimov wrote:
> From: "Hamish Mackenzie" <boost_at_[hidden]>
> > Now the problem is if you don't know the policy how do you catch the
> > exception?
> 
> You don't. If you don't know what the "Throws" clause of the function you
> just called is, don't try to catch a concrete exception. If you don't know
> what the "Effects" clause says (or the "Preconditions", or the "Exception
> Safety"), don't call the function at all. ;-)

I am not sure I understand, but my point was if the ErrorPolicy is a
template argument it's type is not known by the library designer but can
be assumed to be one of the two policy classes given and the compiler
knows which.

The idea is that the end user decides how they want errors to be handled
with something like

  some_class< error_policy_1 > x;
  x.some_function();

some_class in turn may have passed the error policy on to other internal
classes (much like an allocator).

When you write some_function you have to handle a particular error so
you write the code I gave as an example at the end of my post.

You determine the type of the exception that an error number results in
(using type_to_catch) and can check if an exception corresponds to a
particular error number (using check_error_number).

You can still specify the exceptions some_function throws.  But there is
a slight catch there that is the compiler needs to be able to handle the
case that the same excpetion may be listed more than once.

  template< typename ErrorPolicy >
  class some_function
  {
  public:
    void some_function()
      throw( ErrorPolicy::type_to_catch< 3 >,
             ErrorPolicy::type_to_catch< 4 > ) {...}
  };

In terms of the exception guarantee the only thing that changes is the
type of the exception so it should not be affected by the change of
policy (as long as intermediate layers all use type_to_catch and
check_error_number).

some_class could also be specialized to take a policy that requires
errors to be handled by returning error numbers (though it is probably
not a good idea for this version to share its implementation with the
version that uses exceptions).

Another use of the error policy is to add auto retry on certain errors.
The low level library code looks something like
  int retry_count = 0;
  while( system_call() )
    ErrorPolicy::error( errno, retry_count );
Assuming the policy throws exceptions

Tuples can be used to pass other information about the error to the
error policy and the policy can control how much of this information
goes into the exception or log it for debuging.

Hamish