"Eric Niebler" <eric@boost-consulting.com> wrote in message news:43F64354.3010104@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