Re: [boost] [system] error report refinement

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-08-28 10:58:34

Hi Beman,

Beman Dawes <bdawes_at_[hidden]> wrote:
> Although this works well, it has the unfortunate consequence
> of doubling the number of functions. That makes the interface
> harder to understand and is a pain to implement, document, and
> maintain.
>
> A refinement is for the <error_code.hpp> header to provide a
> dummy error_code that is interpreted as a request to thrown on
> errors:
>
>    extern error_code throw_on_error;
>
> Then only a single signature is required:
?
>    whatever foo( error_code & ec = throw_on_error );
>
> On an error, the implementation of foo throws if ec !=
> &throw_on_error, otherwise it sets ec to the appropriate
> error_code and returns without throwing.
>
> This approach gives the user the same choice, but halves the
> number of functions. I can't think of any downside.
>
> Comments?

I'm concerned that, even though it may halve the number of
functions, it actually increases the complexity overall.

Putting my standards-proposal-author hat on, it makes the
specification of the behaviour of the single function more
complex than the original non-throwing version. On the other
hand, under the current approach the "as if" definition of the
throwing version is trivial. E.g. for ip_address::to_string()

  string to_string() const;

    Effects: Calls:

      error_code ec;
      string s = to_string(ec);
      if (ec) throw system_error(ec);

    Returns: s. 

The increased number of code paths in the single function might
also make it harder for the compiler to optimise the code. Even
if you are only interested in using non-throwing functions, you
could end up with the bookkeeping costs (space or time)
associated with exceptions whether you like it or not.

Another thought: from an implementation point of view, there's
no way to ensure that the throw_on_error value is not written to
accidentally (and it introduces a race condition if you do write
to it). That increases the burden on the implementor. This cost
potentially impacts on library users if they want to reuse the
error_code facility in their own functions.

While I appreciate the goal, I'm not convinced this is an
improvement over the current method. I suppose my late night
ramble above is really a round-about way of saying that the
current error_code policy is better because it distinguishes
between the two modes (throwing or non-throwing) at compile
time, not run time.

Cheers,
Chris