Boost logo

Boost :

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

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