For many non-system functions, the careful developer can be guaranteed not to encounter an error if he or she follows the library's specifications. E.g., if we so choose, we can ignore the fact that Boost.Any has a bad_any_cast, because we can ensure we will never see it, and we can likewise ignore many of the possible errors returned by Boost.Regex. For system errors, even design-by-contract will not save us from errors; it's for this reason we need the flexibility. On 2/19/2006 11:08, Beman Dawes wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uslqhv41e.fsf@boost-consulting.com...
Beman Dawes <bdawes@acm.org> writes:
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. Why are system-error-reporting functions special in this regard? The rationale doesn't give me any reason not to think we need to do this with every function that could otherwise throw, regardless of the reason. If that's not the conclusion you want to reach, you should refine the rationale so it describes why system errors are more special than all the other ones.
Good points. I'm going to think about the differences or lack thereof before trying to answer.