Boost logo

Boost :

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-05-22 09:42:58

Hello all,

I have been thinking about how to reconcile Boost.Asio error
handling with the system error classes defined in the TR2
filesystem proposal N1975. I have some concerns which I'll
outline in the context of how I plan to use them.

The current plan is as follows:

- Synchronous functions would by default throw a system_error

- An overload of each synchronous function would take an
  error_code& as the final argument. On failure these functions
  set the error_code to the appropriate error. On success, the
  error_code is set to represent the no error state. These
  functions do not throw exceptions.

- Callback handlers for asynchronous functions would take an
  error_code as the first parameter. For example:

    void handle_read(error_code ec)

- Since many error codes in socket programming are "well-known"
  and often tested for explicitly, they need to be defined
  somewhere. The current errors in the asio::error::code_type
  enum would be replaced by constants of type error_code:

    namespace boost {
    namespace asio {
    namespace error {

    const error_code access_denied = implementation_defined;
    const error_code message_size = implementation_defined;

    } // namespace error
    } // namespace asio
    } // namespace boost

  (Note that in practice boost::asio::error might actually be a
  class with static members rather than a namespace).

The issues I have run into so far are:

- The error_code class seems to assume that there is a single
  "namespace" for the system_error_type values. This is not
  necessarily the case for the errors in socket programming.
  For example on UNIX most socket functions use errno values,
  but the netdb functions (gethostbyname and friends) use a
  different set of error values starting from 1, and the
  getaddrinfo/getnameinfo functions use another set of error
  values starting from 1.
  Would it be possible for the error_code class to have a
  category value (which is probably an integer with
  implementation-defined values) to allow the creation of unique
  error_code values for each type of system error? A category
  value would also allow implementors and users to extend the
  system error classes for other sources of system error (e.g.
  SSL errors, application-specific errors, etc).

- A common idiom in code that uses asio, when you don't care
  about a specific error type, is to simply treat the error as a

    void handle_read(asio::error e)
      if (e)
        // take action because of error
        // success

  Can the error_code class be made convertible-to-bool and also
  have operator! to support this style?

- Are these classes available in CVS somewhere so they can be
  reused by other boost libraries?


Boost list run by bdawes at, gregod at, cpdaniel at, john at