Re: [boost] [system] Was: Re: [asio] Breaking changes committedtocvs HEAD

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-11-15 07:22:05

Hi Johan,

Johan Nilsson <r.johan.nilsson_at_[hidden]> wrote:
> Extract from that original posting:
>
> Guidelines:
[...]
>    Such functions should also have an overload that takes an
>    additional argument of type boost::system_error_code& ec.
>    The behavior of this overload is the same as the
>    non-overloaded version, except that it does not throw an
>    exception on an API error, and it sets ec to the error code
>    reported by the operating system, or to 0 if no error is
>    reported.
[...]
> The second paragraph leads to the implementation being exposed
> through its interface.

I'm a little confused by this statement. Can you expand on it? I
don't understand how it's relevant to the discussion, i.e. how
it's different from a function that sets errno (or equivalent).

> OTOH, usage of error_codes could also cause that kind of
> latent errors:
>
> -----------
> error_code const& foo(error_code& ec)
> {
>     if (!SomeWindowsAPICall())
>     {
>         return ec; // oops, forgot to set ec
>     }
>
>     ... do something ...
>     ec = error_code(); // success
>
>     return ec;
> }
> ----------

Hmm, I wouldn't class that as the same kind of error at all as
the problem is clearly evident in the function itself -- it
doesn't involve hidden side effects of a separate function. The
error code value represented by errno/GetLastError is a
thread-specific global, and IMHO is bad for the same reasons as
why globals are considered bad.

On a related note, this whole issue with functions having the
side effect of modifying errno is the rationale for an
error_code_preserver class. If you don't have the side effects
in the first place, you don't need an error_code_preserver
either.

> I'm not "blessing" anything.
> 
> Also, the TSS-based suggestion had nothing to do with my
> "don't pay for what you don't use" statement - that was only
> referring to the Set/GetLastError/errno wrapper. Those might
> be TSS-based (or equivalently implemented), but that was not
> my point.

I meant that putting a portable wrapper for errno / GetLastError
/ SetLastError in the public interface of the system library
would effectively bless that style of error handling for use by
a wider C++ audience. I'm not in favour of that.

BTW, I was just using "TSS-based" as a shorthand for errno and
GetLastError (or any wrapper of them) that behaves as though
there is a separate error code per thread, and not a comment on
how they're implemented. Perhaps "thread-specific error code" is
a clearer term.

Cheers,
Chris