Re: [boost] Operating System API Error Reporting Guidelines

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-02-17 21:42:49

"Eric Niebler" <eric_at_[hidden]> wrote in message 
news:43F64354.3010104_at_boost-consulting.com...
> Beman Dawes wrote:
>
>> Do other Boosters like the idea of an overall guideline for dealing with
>> operating system API error reporting?
>
>
> Sure.
>
>
>> Do the specific guidelines make sense? How can they be improved?
>
>
> What about system calls that fail in a constructor? Providing a no-throw
> constructor that could leave an object in an invalid state can make it
> much more difficult to reason about program correctness. What is the
> recommendation in this case?

Good question. In Boost.Filesystem, the only no-throw constructor added so 
far was for directory iterators, and those can be left in a valid state (the 
end iterator). The case you mention is a strong argument for not supplying a 
non-throwing version 100% of the time. There may be some other cases where 
the usefulness of either the throwing or non-throwing version is 
questionable.

I'll think about this a bit more and draft some additional wording.

I also meant to add wording to the effect that if a destructor does 
something that might result in an API error, there should be a close-like 
function with both throwing and non-throwing versions that performs the 
error-possible API operation. The effect of the destructor is just to call, 
if needed, the non-throwing version of that function.

> Some people may want to make the exception-throwing versions unavailable
> to guarantee they don't accidentally call one. There should be a
> recommended way of doing that (eg., a standard PP macro).

Interesting. Such a macro only makes sense if both throwing and non-throwing 
versions are available for most or all functionality.

Thanks for the comments,

--Beman