Re: [boost] Operating System API Error Reporting Guidelines

From: Eugene Talagrand (boostdevel_at_[hidden])
Date: 2006-02-21 01:04:12

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_at_[hidden]> wrote in message 
> news:uslqhv41e.fsf_at_boost-consulting.com...
>> Beman Dawes <bdawes_at_[hidden]> 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.