Re: [boost] [asio][filesystem] system error handling

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-05-23 19:15:33

Hi Beman,

> > - Callback handlers for asynchronous functions would take an
> >  error_code as the first parameter. For example:
> >
> >    void handle_read(error_code ec)
> >    {
> >      ...
> >    }
>
> That makes sense to me. It wouldn't be useful to throw an
> exception because of the asynchronous nature of the control
> flow, so supplying a error_code to the callback gives it a
> chance to deal with the error, or ignore it if desired. Was
> that your analysis?

Yep, exactly. The current asio::error exception class currently
fills the role of the error_code in async callbacks, as well as
the system_error in throwing sync functions.

> I haven't thought of the case of several "namespaces" or
> "errorspaces" before, so please take what follows as an
> initial idea, not something cast in concrete.
>
> My initial thought is to leave error_code alone, since it
> should be fine for most uses. For uses that need more
> information, such as asio, derive asio_error_code from
> error_code, adding appropriate members. For example, members
> to set/get the well known socket error codes.

Couldn't that introduce a problem with slicing? The error_code
is passed by value to functions like system_message(), the
system_error constructor etc.

I suppose I'm not thinking of the asio errors as having more
information as such. From the user's point of view they are
system errors like any other. It's just from an implementation
point of view that we have these multiple error spaces. This is
mainly a problem for UNIX where some of the system APIs don't
use errno values.

When I was thinking about it before, I wasn't sure whether it
was better to make the category part of the interface or simply
allow the implementation to add a category as part of the
implementation-defined system_error_type.

Another aspect that appeals to me with having well-known errors
as constants of type error_code, is that it allows most users to
treat the error_code as an opaque type. They can write:

  void error_handler(error_code ec)
  {
    if (ec == asio::error::eof)
      ...
  }

without needing to worry about the implementation-defined value
of asio::error::eof, or indeed care what implementation-defined
error space it lives in.

> > - Are these classes available in CVS somewhere so they can
> > be reused by other boost libraries?
>
> No. I was waiting for 1.34 to ship, but that is taking a long
> time so I'll go ahead and update CVS head, hopefully tomorrow.

Great, thanks!

Cheers,
Chris